On Sat, Apr 09, 2011 at 03:59:34AM +0200, Cedric Cellier wrote: > > Sorry, I don't know mips assembler at all, or gas. > > I run this into gdb, I 'stepi', and I don't see the proper values loaded > > into the floating point registers. > > > > Is it me doing something wrong? It looks like those ldc1 go compiled into > > totally different instructions, not referring to 'a' or 'b'. > > mips is such a strange beast that its assembly language is composed of many > macro instructions that the assembler understand and replace with other, > simpler ones. Also, the assembler frequently reorder instructions. This is > very annoying when you do some serious programming in assembler (because if > you wanted the help of a program to find out the instructions to output then > you wouldn't use assembly language in the first place), but I suppose this > was designed to help higher level languages compilers to deal with mips > singularities.
Interesting. I think that i386 had also some very few cases like this. But very few. I have this little remember from when I switched from 'debug.exe' to 'tasm' in DOS, assembling. > So, no worries if the code does not look like the above one when > singlestepping in gdb. The final values loaded into the registers should be > the same. They are not when I check. I checked the addresses loaded (doing the pointer calculations wit gdb stopped at the start of main()), and I end up at addresses that are not those of 'a' or 'b'. And there are the values loaded into the fp registers, which are not those set at 'a' or 'b'. I see the pointer arithmetic in the generated assembly is done from the 'gp' register, that maybe is not loaded properly? > Now for our problem (madd.d raising an exception for some values and some > registers) I cannot investigate further until monday evening, having no mips > at hand for now. But it would be interresting to know what exception is > raised precisely, because IIRC that could also be an unimplemented > instruction exception that the fpu is allowed to raise for some values in > some circumstances if it feels like it, according to the manual which does > not states which circumstances exactly. Stopped just before the exact instruction raising the SIGILL: cause: 0x10008024 Just after: cause: 0x1000803c If I understand correctly, this is an 'overflow' exception. Isn't it? I have little idea about all this :) But I'd like to find out. -- You received this message because you are subscribed to the Google Groups "loongson-dev" group. To post to this group, send email to loongson-dev@googlegroups.com. To unsubscribe from this group, send email to loongson-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/loongson-dev?hl=en.
