Re: [uCsimm] about 32-bit PIC

From: 권석근 (
Date: Mon Jan 10 2000 - 22:07:47 EST

BTW, excuting code on flash does not show complaing and
this is because kernel treat code on flash diffrently, i've seen
is_in_rom() fuction in the kernel. Is this right?
But if i want to run app. on RAM DISK (not on flash), then
kernel kmalloc patch is needed, and Alexander V. Komarov
said that it was already done in 2.0.38pre1 (I'm lazzy, ha,
i must upgrade my kernel).

Erwin Wrote:

In your example, the .data section will be too large.
The 32-bit PIC patches don't change the .data+.bss limits.
If you are executing code on a NFS mounted directory,
the current kmalloc complains if the .text segment is larger
than 128k. Thus, the unlimited .text segment is only
available when the application is burned into flash.
I have now modified the gcc patches to use a0 instead
of a4, because a0 may be used in calls without saving anyway.
Thus, the "old" 16-bit PIC may be mixed with 32-bit PIC
without any restriction now, as long as the 16-bit offsets are
not out of range. For my tests, I have left the C library
with 16-bit PIC, the only file that has to be modified is
crt/crt0.s. I removed _cleanup from the crt0.s and added
it as a dummy function at the end of my application.
The "bsr exit" has to be changed to a 32-bit call.
I believe it would be best to make 32-bit PIC a compiler
option for m68k-pic-coff:

-fpic (or no option) for 16-bit PIC, this is used by default now.
-fPIC for 32-bit PIC

Other ideas or suggestions are welcome.


diff -U1 crt/crt0.S.orig crt/crt0.S
--- crt/crt0.S.orig Mon Jan 10 16:01:33 2000
+++ crt/crt0.S Mon Jan 10 16:03:05 2000
@@ -32,3 +32,4 @@
        move.l %d0,%sp@-
- bsr exit /* Invoke exit() routine */
+ lea exit-.-8,%a0
+ jsr 0(%pc,%a0) /* Invoke exit() routine */

@@ -45,5 +46,2 @@

- .global _cleanup
- rts /* nothing to clean up */

diff -U1 config/m68k/ config/m68k/
--- config/m68k/ Wed Jan 5 13:25:34 2000
+++ config/m68k/ Mon Jan 10 17:50:57 2000
@@ -810,3 +810,4 @@
- "lea %a1(%%pc),%0")
+;; 32-bit offset for text seg. load
+ "lea %a1-.-8,%0\;lea 0(%%pc,%0),%0")

@@ -5993,3 +5994,3 @@
- return \"bsr.w %0\";
+ return \"lea %0-.-8,%%a0\;jsr 0(%%pc,%%a0)\";
@@ -6066,3 +6067,3 @@
- return \"bsr.w %1\";
+ return \"lea %1-.-8,%%a0\;jsr 0(%%pc,%%a0)\";

권석근[] wrote:
> hi,
> 32bit-pic patch was proposed a few days ago by Erwin.
> I've tested 32bit-pic patch last night, and got following result.
> i compiled libc, crt0, libgcc with 32bit-pic patched compiler.
> and test following code (i patched crt0.S with 32bit pic call)
> ----------------------------------------
> /* test.c */
> char a[65536] = {
> 'h','e','l','l','o',',','w','o','r','l','d',
> [11 ... 65535] = 0; };
> main()
> {
> printf("%s\n",a);
> }
> ----------------------------------------
> Erwin was right of cource, 16bit-pic compiler complained with code size,
> and 32bit-pic compiler generated working (excutable) code.
> But after compiling another useful app ('rc', another shell from elkscmd),
> i found that i still have code limit 128K. it's because kmalloc() at
> time.
> Compiling 'rc' with 32bit-pic was successful, but actually it didn't run
> uCsimm. With some experiences before, I tried add more stack area (it was
> guess) using
> coff2flt command, and tried to rerun. At that time, kernel said
> "kmalloc of too large a block (...)".
> It meant that kernel do not accept app which have "text+bss+data" above
> 128K.
> I retested above (test.c) code with stack size 65536, and got the same
> message
> from kernel.
> And that's all.
> My conclusion?
> Generally speaking, large code size could be a problem for uCsimm.
> Thanks.
> BTW, how could i debug my program with gdb on uCsimm?
> This message resent by the list server

This message resent by the list server

This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:33 EST