Some possibly silly questions regarding float, double &

[Tychom]

So today I passed the next stage in the development of my game (info + vid here) but not without some trouble.

The first problem I had was regarding comparisons of floats, i.e. something as simple as this (where 'x' is of type float):

Code: Select all

if &#40;x < 1.0f&#41;
&#123;
	//something here that won't be optimized away..
&#125;

resulted in an error - "opcode not supported on this processor: r4000 (mips3) `c.lt.s $f2,$f0'". Which is rather worrying.

A second issue came from double precision values and any use of them with other types, resulting in "undefined reference to `fptodp'" and a few associated functions, this is much less of a problem.

I'm wondering if there are any workarounds to the above, through compiler or linker flags...?

Last off I'm curious about library code the likes of which you'd find in math.h. I went straight off today and assumed no such thing exists yet and dealt with some approximations of tan etc, but would I be incorrect here?

[Grover]

I think this is a compiler problem - Im trying to rebuild gcc with a set of r4000 cpu sources, which will hopefully resolve this. As far as I can tell.. both the 64-bit and 32-bit r4000's cupport c.lt.s .. in all cases. Hence.. why I think the compiler might be at fault.

For a quick fix for this just test the sign bit on the float :-) bit 31..

[Tychom]

For a quick fix for this just test the sign bit on the float :-) bit 31..

Already gone there, it's as if you're reading my mind :)

[Guest]

Most like a gcc problem for sure. The EE's ISA has had some differences concerning the c.lt.s instruction as shown here in the binutils patch for the toolchain.

Code: Select all

-{"c.lt.s",  "S,T",	0x4600003c, 0xffe007ff,	RD_S|RD_T|WR_CC|FP_S,	I1	},
+  /* The r5900 has a different bit pattern for the c.lt.s instruction. 
+     In order for the disassembler to be able to locate the correct pattern 
+     its bit mask (0x46000034) must appear before other patterns with the 
+     same bit mask.  In order for the assembler to work, all patterns with 
+     the same name must appear consecutively.  Hence the c.lt.s patterns 
+     appear here, out of their natural order.  */
+{"c.lt.s",  "S,T",      0x46000034, 0xffe007ff, RD_S|RD_T|WR_CC|FP_S,   T5      },

Basically, it seems the ISA level 1 definition was removed. Only the 5900 ISA specific definition replaced it, and the only other definition is ISA level 4 (I didn't paste that one in but it followed the 5900 T5 definition).

Since MIPS4k is ISA 3 IIRC, the replacing of the ISA 1 definition for c.lt.s may be the root cause of this problem, since there effectively seems to be no valid c.lt.s for ISA <=3 outside of 5900.

We may need to review if any other opcodes that need to be valid for MIPS4k (ISA 1,2,3) are similarly trampled...

[Guest]

Hmm, actually compiling with ISA of MIPS32 should work around this problem, since the I4 definition of c.lt.s is "or'ed" with I32.

I don't recall the exact flag, but try -march=mips32 or something similar. Check the man page. :)

[Grover]

I was wondering that the gcc built for ps2dev kit was actually built for the r5900? hence the missing ISA implementations. I have used the -march=mips32, with no luck.

Also on another note, is the PSP r4K a 64-bit or 32-bit series (there are many) does anyone know for sure the type it is? Its not a r6000 derivative.. since the differences are actually very minor between r4400 and r6000..?

[Guest]

I was wondering that the gcc built for ps2dev kit was actually built for the r5900? hence the missing ISA implementations. I have used the -march=mips32, with no luck.

Also on another note, is the PSP r4K a 64-bit or 32-bit series (there are many) does anyone know for sure the type it is? Its not a r6000 derivative.. since the differences are actually very minor between r4400 and r6000..?

Its the standard gnu compiler with support for 5900 added. So it still has support for all other MIPS, at least, so far as adding support for 5900 did not disturb the support for other ISAs.

My understanding was that it was a MIPS4000 32-bit derivative, not R4400 or any 64-bit derivative. I hope someone corrects if I am mistaken.

Give time for the toolchain folx to look closely at whether mods for 5900 support are stomping other things. :)

[blackdroid]

the r4k in the psp is strictly 32bit, no 64 bit opcodes work ( apart from daddu, but it doesnt add numbers, still havent figured what daddu is on psp r4k ).

the fpu doesnt have acc so msub, msuba, madd etc wich exists on ee, so dont use those opcodes.

the dp emulation exists in libgcc, so unless you link with a valid libgcc ( ee libgcc wont work nicely ). One way to get rid of dp references is to always use the f suffix, or compile with -fshort-double

[Grover]

Welp. I am pretty sure whats happening is that the cross compiler has only been built for the r5900. If you try other -mcpu options you will find that the compiler cant build them (unrecognised option). Essentially by specifying -mgp32 the compiler builds only for the 32bit assembly of the r5900.

I beleive a mips32 assembler needs to be made for cross compiling to a 32bit cpu. Im in the process of doing this now, and will see what happens. I assume this is roughly what needs to be built for:
http://www.mips.com/content/Products/Pr ... oductBrief

[Guest]

Welp. I am pretty sure whats happening is that the cross compiler has only been built for the r5900. If you try other -mcpu options you will find that the compiler cant build them (unrecognised option). Essentially by specifying -mgp32 the compiler builds only for the 32bit assembly of the r5900.

A gnu toolchain already exists. MIPS4K support already exists within the basic GCC compiler. If you don't like the ee-gcc variant, don't use that one. Just download the normal gnu compiler and build a generic mips R4K cross that doesn't use the PS2DEV patches.

Seems you are duplicating work thats been long done.

[Grover]

Im not duplicating anything.. just rebuilding the cross compiler? so I end up with a r4000 set of binutils? this is right isnt it? Last was when I built one fer ps2 about 3 yrs ago? I realise fully gcc has plenty of cross platform targets.. thats why Im doing it? and the current ps2dev.. is definitely an M64r5900 assembler.. hence the issues when building 32 bit.. there is no M32r4000 bin utilities at all (thats because ps2 doesnt need it?)...

and you'll be happy to know it was successful..

[Guest]

Ok. Happy. :) Good job. ;)

[Grover]

Quick q too - qould it be a good idea to put up a zip of the compiler + libs (i used newlibs so should be okay for most stdlib gear). Or is there going to be a pspdev made up like the ps2dev? just wondering?

Sorry I sounded grumpy.. hehe I should be sleeping..

<edit> actually ignore that.. since I built it without setting a more generic host :-) doh!.

[Guest]

well, all you should have needed to do was proper ./configure's for binutils and gcc. :) Maybe we can just document what they were ? :)

[Grover]

Yeah. binutils went mostly ok - minus the yacc issues (you have to manually run through some steps that dont seem to happily go through automake).. and gcc needed some manual modifying (some c files dont build properly and some compiler settings fall over too).. yes, I sort of wish I had written it all down.. I havent slept yert.. so getting groggy (im in Aus).. will run thru settings tonight and doc it..

<edit> Just found something a little funny :-) .. mips website has a free gnu toolchain for all its processors :-) .. Im betting that will be a little more optimised and likely to produce good code.. :-) .. nuther night wasted..
http://www.mips.com/content/Products/So ... ntent_html

doh..

[blackdroid]

the compiler itself doesnt produce better code than the equivalent gcc version, however some of the libs have pretty good code, albeit most of that is math and something you would want to offload onto vfpu anyway.

Making ee-gcc produce usabel 32bit code isnt hard btw, the only problem is that you can not use ee-libgcc. This is the reason why none has stepped up to produce a psp-gcc, since we know too little about the special r4k opcodes on the psp, and the vfpu, until then ee-gcc will work nicely, yes even with floats.

[Grover]

If it works with floats then whats the fix for the c.lt.s problem? Looking at the MIPS instruction set 4K is wildly different to 5900. Sure the opcode may translate is some way, but as far as I can tell they are actually substantially different devices? Unless the 4K on the MIP website is different aagin to the the one in the PSP? When you use the 5900 as 32bit, you cannot necessarily produce the right opcodes without a set of 4K binutils? (btw Im only working on what people have put up about the PSP being a MPS 4K.. )

I would think too the MIPS sde def does produce better code - its like the ADS ARM compiler, they have used their own MIPs based info to produce this. The sde-gcc mips options for example are quite different to 2.95, or 3.x.. and the docs mention that they have put effort into this (as most chip manufacturers do). The libs would also be definitely use, since they will have all the std libs prebuilt for the target (there are a boat load of targets in the libs dir).

Anyway thought it might be more sensible to use the MIPs provided gear anyway, since its very likely what Sony use (albeit modified to match the necessary changes). BTW.. that ee-gcc build looks alot like the compiler Snsystems released about 2 yrs ago? Is it the same one?

[Guest]

Anyway thought it might be more sensible to use the MIPs provided gear anyway, since its very likely what Sony use (albeit modified to match the necessary changes). BTW.. that ee-gcc build looks alot like the compiler Snsystems released about 2 yrs ago? Is it the same one?

Sony and game developers are all using GCC for PS2 and PSP. And no, its not the compiler from Snsystems, though since Sony released *some* patches to GCC for the ps2 (yes, gcc was used for PS2 professional development too) they made their way into other versions of the gcc toolchain.

Look, the magic is all in binutils, in the opcodes list for all MIPS variants. There are little differences in many variants, and remember, the PSP's are "derived" from 4K - chances are good Sony modified some opcodes like they did on the 5900, and there are still the opcodes for the vfpu we don't know.

Please take a hard look at the binutils patches for 5900 to understand the scope of this problem. Its really not a difficult thing to fix. It just takes someone motivated to do it.

[Grover]

Sorry I did actually work on the gcc chain on PS2 as a devver about 3/4 yrs ago. Snsystem actually were forced to release their 2.95.2 compiler becuse it was GPL'd gnu compiler.. the subsequent ones they made afterwards were different. If you run the info on ee-gcc I saw it was similar to the one released. So please dont get me wrong.. I was only pointing out what I had seen before.

The MIPS SDE compiler _is_ gcc.. but a specifically built one to support all their variants.. (obviously the PSP is not a specific target though).. same as the ADS one for GBC.. and thier wirless ARM chips.. same as what most manufacturers do for their chips. And they are built

Okay.. so noone has built a binutils for r4k then? Why say that there was then - blackdroid says ee-gcc works fine with floats? Im getting very confused about what you guys are doing? And I dont see how saying these things helps anyone?

Is there a simple patch available for the float compares or not?

[Guest]

I thought I already stated that the ee-gcc compiler will emit for all MIPS variants also, I have no idea how you could have thought otherwise. Its merely targeting for r5900 to be the default. *BUT* the apparent bug that I pointed out, introduced from our patch prevents it from working if you go and specify -march=r4000 -mtune=r4000 -mips3, producing the error you see. If you studied the entire mips-opc.c file from binutils, you should see what I mean. I don't think anyone stated they made a binutils for 4k, I think everyone is stating they are using ee-gcc + binutils(ee) as-is without trying to make it produce r4k specific code - relying on the r5900 code it emits.

If by your statement referring to 3/4 years ago you *used* the gcc compiler, I believe you. I don't get the impression there is much else you did with it. Having pointed out to you exactly where the problem is, the source file, and a code snippet, you proceed to ignore it and speculate off in the opposite direction about what could be wrong.

The only reason I hadn't gone off to actually produce a patch yet is because you seemed motivated to fix it yourself and I assumed you were capable of understanding the material I have told you. There is nothing wrong with you maybe not understanding it, since we are all at different levels in the pursuit of knowledg; except that you insist you really do know what you are doing in trying to solve it, and clearly you do not.

If you were off in the desert and dying of thirst, and someone walked up to you to offer you a glass of clean pure water, you would find fault with the water and insist on being taken to that mirage of an oasis over the horizon. At least, judging by your actions so far.

If you think the way people are responding to you is not helpful, its because you are not actually reading what they say, and they are frustrated from continually helping and being played second fiddle to a mirage.

Now pardon me while I go off and make thee a patch. But do not begrudge me the right to chastise you.

[Grover]

nice.. okay. I'll go then.

Maybe you should read what I wrote.. I wasnt building an ee-gcc at all.. blackdroid seemed to think ee-gcc works fine with floats.. (which conflicts with your comments) and you seem to think ee-gcc can build many different variants.. have you tried it?

[Guest]

Well, dunno what you were doing with binutils then if you weren't building a new compiler, I thought thats what you were doing. EDIT: and yes you did say you were building a gcc, and building gcc in general for MIPS is what we are talking about. Seems I am reading what you are writing just fine, but I hope you don't have any hangups about the ee- prefix on gcc, the result is still gcc regardless.

No blackdroind and my comments do not conflict. Things work fine if you just use ee-gcc with the default target of r5900, which is the point blackdroid made.

The bug is produced when you ask the compiler to emit for the r4k variant using -march=r4k -mtune=r4k. This is what I am patching (though not terribly useful patch at the moment since there we do not know yet all of the opcode differences between PSP's r4k variant and a pure mips 4r4k.

Yes ee-gcc can emit code for many variants, this is what gcc has always been capable of doing. Of course I tried it.

[blackdroid]

I would think too the MIPS sde def does produce better code - its like the ADS ARM compiler, they have used their own MIPs based info to produce this. The sde-gcc mips options for example are quite different to 2.95, or 3.x.. and the docs mention that they have put effort into this (as most chip manufacturers do). The libs would also be definitely use, since they will have all the std libs prebuilt for the target (there are a boat load of targets in the libs dir).

Even then its based on gcc-2.96, gcc has come along way since then, especially for RISC based cpu's.

And yes current ee-gcc looks alot like old snsys.

There is nothing wrong with you doing a r4k binutils and gcc and you dont have to deal with compiler flag magic, just that its just that a r4k gcc, and until we have enough knowledge about vfpu and the special opcodes that sony added to the r4k core I dont feel all that compelled to start working on a psp-gcc.

[Guest]

Just as a followup.

In short, due to mods made to EE binutils opcodes/mips-opc.c the definition for the c.lt.s instruction (compare, less than, single precision) becomes undefined for ISA's 1,2,3 (3 being the canonical level for r4000). It (c.lt.s) was originally defined for ISA level 1, which was replaced by the EE custom definition. The only remaining definition was for ISA level IV or ABI level 32. Thus, -march/-mcpu=r4000 is left in the cold with the the patches for the PS2 binutils.

However, with MISP32 lies salvation.

The original MIPS R4K was a 64-bit cpu that represented the canonical ISA level 3 in GCC, which also includes 64-bit integer arithmetic. However, most of the current R4K derivative cores offered by MIPS nowadays appear to be 32-bit versions using the MIPS32 ABI. We know from Sony that the r4000 in the PSP is a 32-bit architecture, not 64. Thus, isn't it more likely that the ABI level is MIPS32 ?

I have found that using the following flags with ee-gcc causes this problem to go away, and may even be more appropriate to use with the PSP.

ee-gcc -mabi=32 -mgp=32 -mfp=32 -mlong=32 -mdivide-breaks ...

(adresd also suggested -mdivide-breaks because traps may not work on the PSP for catching div by 0).

Now, I haven't thoroughly tested this for side-effects or perfection. But I do know at least 2 instructions were lost in the original problem above will hopefully now be accessible. Also, it is worth noting that the above instructions will not work with the crt0.s supplied by the EE part of the toolchain, which is compiled for a 64-bit ABI. For now, one might try using the crt0.s supplied with Nem's hello world. I hear someone has a r0x0r crt0.s that might be released eventually. ;)

All of this may be soon moot as people are working feverishly on a GCC 4.0 PSP specific toolchain, but I just wanted to send an update. A true fix to this would be to fix the binutils patch so that the right thing is done (i.e. allow the compiler to properly support many different MIPS targets without fail, in addition to the normal default EE target it is configured to be).

[alonetrio]

hi and thanks for all your tips.

since un change my flags with the one you mention, get now strange execution comportement.

Code: Select all

unsigned long tabpointx[14],ame=0;

 tabpointx[0]=10;
 ame=0;

 // here is i check the value //

when i check tabpointx[0+ame*14] it return 0 !!!
but if i check tabpointx[0+0*14] it return the good value 10.

any idea about this strange thing ?

AloneTrio

[Guest]

No idea, but can you paste more code ? For example, I would like to see how you are checking the value.

I am trying to test the same thing you post, using my toolchain, but I broke the toolchain recently, so may be one more day before I can test again.

I did check asm output of the code and see no difficulty, but I do not execute yet on the PSP.

[alonetrio]

the code is exactly this and to test i just add a pgPutPixel to test my value.

Code: Select all

 unsigned long tabpointx[14],ame=0;
 tabpointx[0]=10;
 ame=0; 

pgPutPixel(tabpointx[0+ame*14],0,0xefff); // this plot at 0,0
pgPutPixel(tabpointx[0+0*14],0,0xefff); // this plot at 10,0

i can provide a "not" working source file if it need.

AloneTrio

[Guest]

I tested the compiler with -mabi=32 on nem's helloworld and it worked fine. I even threw in some dummy if (float1 < float2) ... statements in they were passing the assembler stages without any trouble. So without the entire code don't really know whats up.

[alonetrio]

gorim, i posted you a simple sample about it in pm. tell me what you
think about it.

AloneTrio

[Guest]

Sorry, it will be perhaps one more day before I can look at it. I had 2 hours sleep last night, and I have to work 16 hours today, then sleep and go to work again. I normally cannot work on these things during my job.