>Both the "old" 16-bit PIC binaries as well as my 32-bit patch use
>the same flat format, and both can be converted with coff2flt.
>You can even mix 16-bit and 32-bit PIC objects as long as
>a) the 16-bit objects have no references to modules that are >32K away,
>b) you don't call functions inside 16-bit object modules from 32-bit
case a),b) assumes mixed 16bit-pic and 32bit-pic objects.
Then, if i compile all library and utils as 32bit-pic objects, there must
problems. right? sounds good!
Does anybody have another idea? I saw some inline asm code in the libraries.
Are there some inline asm code that currupt a4 register? i'm not sure.
my guess is almost all inline asm code is a4 safe but i didn't check all the
If all sources are correctly compiled with 32bit-pic, then i'll jump into
world, we have all souces (including app/util/lib) doesn't it?
I'll start checking for inline asm.
I'm missing Bernhard's RT porting. i agree that module support is not a
mandatory for RT uCsimm. Compiled rt-task with kernel with basic
interrupt handling layer might be best in my opinion. I want to hear
news from Bernard. thanks.
This message resent by the firstname.lastname@example.org list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:33 EST