Re: "small data" in m68k gcc?

Re: "small data" in m68k gcc?

[Bernardo Innocenti]

On Sunday 12 October 2003 23:49, colin-gcc@horizon.com wrote:

> I asked about this on gcc-help, but nobody had a useful suggestions,
> so I'm searching further afield for useful suggestions.

I've forwarded this to Gunther Nikl who is probably confident
with the small-data model used on the Amiga.


> I'm trying to move some code away from a proprietary compiler, but
> the multitasker depends on having A5-relative global variables, and
> I'm having a hard time figuring out how to generate them.

This has been quite common practice on the Amiga to generate residentable
programs and reduce code and relocs size. Actually, the Amiga uses
A4-relative addressing because A5 is used as a frame pointer and A6 is
reserved for calling shared library functions through a jump table.


> -fpic generates an 15-relative table of pointers to global variables,
> but that's a lot slower.  16-bit offset addressing modes are smaller
> and faster than the 32-bit absolute addresses that GCC usually generates.

Yes, that's the GOT. It allows more than 32KB of data, but it's somewhat
slower.

I've recently committed patches on mainline (will-be GCC 3.4) to
support two new addressing modes used in uClinux:

-msep-data uses the GOT scheme for data, but prevents saving and
restoring A5 and reloading it each time with the GOT pointer.

-mid-shared-library is an exotic scheme with a double indirection to
symbols in text and data segments. It allows scattering a program
and its libraries in memory. Code does not need to be relocated,
therefore a single copy (perhaps in ROM) is shared by different
processes.

The AmigaOS patches Gunther Nikl has probably implement something
closer to your need, but they've not yet been merged into GCC.


> I'd also like to be able to heve "true globals" in the low 32K of memory
> addressed with the 16-bit absolute addressing mode.

This would require adding a new attribute for declarations.
Something like __attribute((zero_page)).


> To round it out, ideally some read-only data could usefully use the
> PC-relative addressing mode.

This is also possible. GCC already places const data in the text
segment and you can use the PLTPC or GOTPC addressing mode to
retrieve it. Assembler support is required, but GAS has it already.

There's currently no distinction between -fpic and -fPIC in the
m68k back-end. If you want to generate optimized code for small
programs (less than 32KB of code), you'll have to hack into m68k.md
to use 16bit displacements instead of 32bit.

> Of course, some data might not fit into the 64K spaces, so a 32-bit
> absolute address would be required for it.

The smartest thing would be having the linker perform this
optimization automatically for relocations <32KB.

It's somewhat perverse to let the linker mess with assembly code,
that's probably why nobody ever did it.


> I was hoping that there was an m68k-specific variable attribute that
> could specify one of the four addressing options to use for references to
> a particular variable, and a command-line option to pick the default one.

There's currently nothing like this in GCC, but it _could_ be added
with some effort.

> It seems like the ort of useful thing that someone has probably
> implemented over the years.

The Amiga people always enjoied A5-relative addressing with SAS/C
(formerly known as Lattice C) and Storm C.

I'm almost sure GCC patches for AmigaOS offer something similar,
and it would be a nice thing to have also for other m68k platforms.

Of course smart A5 addressing requires some support in the startup
code (loading A5 for the first time).

Programmers must be careful when mixing code compiled with small-data
with code using A5 as a general purpose register. On the Amiga,
you'd use the "__loadds" function attribute for callbacks and softints.


> However, I'm having a hard time finding anything like this, even basic
> (a5)-relative globals for the original MacOS.

Hmmm... perhaps there are rougue patches for MacOS that have
never been contributed to GCC. The AmigaOS patches have been
floating around for several years.


> Even the -l option to gas, which is documented as changing the
> default absolute addressing mode to .w (rather than .l), doesn't
> seem to work.

That's not meant to be used to trick the compiler. It's just
a compatibility option for assembly source written for other
assemblers.


> Do you know if something like this exists, or if it could be easily
> hacked in?  I'm a bit lost in the code, but it *seems* like it
> shouldn't be too difficult.  I just want
> 
> attribute((abslong)) -> var.l
> attribute((absshort)) -> var.w
> attribute((based(%a5, base_value))) -> (var-base_value)(%a5)
> attribute((pcrel)) -> var(%pc)
> 
> For a simple implementation, the last one can just generate invalid
> assembly code if you try to write to it.

It _can_ be done, I'm sure, but there's currently no support in GCC.
Most of the changes to support this would go into the machine
description file (m68k.md).

If you want to give it a try, I suggest working with a snapshot
of GCC 3.4. After several years of stagnation, the m68k back-end
has undergone a massive cleanup and is _much_ easier to work with
now.


> For *really* small applications, I can define a "struct globals {}"
> and just refer to that everywherem but that really distorts the code
> and makes porting a pain.

Yes, I know what you mean. I wrote embedded C code for small devices
and I had to resort to those tricks myself. Compiler support is
definitely needed to do such things.

> Can you point me to any hints?

I hope I've not confused you more :-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html

Re: "small data" in m68k gcc?

[Richard Henderson]

On Mon, Oct 13, 2003 at 01:13:55AM +0200, Bernardo Innocenti wrote:
> There's currently no distinction between -fpic and -fPIC in the
> m68k back-end.

Sure there is.  The former generates 16-bit offsets from pic register,
the later generates 32-bit offsets.  Which is why -fPIC isn't available
on ColdFire.



r~

Re: "small data" in m68k gcc?

[Gunther Nikl]

On Sun, Oct 12, 2003 at 05:46:40PM -0700, Richard Henderson wrote:
> On Mon, Oct 13, 2003 at 01:13:55AM +0200, Bernardo Innocenti wrote:
> > There's currently no distinction between -fpic and -fPIC in the
> > m68k back-end.
> 
> Sure there is.  The former generates 16-bit offsets from pic register,
> the later generates 32-bit offsets.  Which is why -fPIC isn't available
> on ColdFire.

  Wouldn't it be possible to load the offset into a register and use that
  one to index into the pic table?

  Gunther

Re: "small data" in m68k gcc?

[Gunther Nikl]

On Mon, Oct 13, 2003 at 01:13:55AM +0200, Bernardo Innocenti wrote:
> > I'm trying to move some code away from a proprietary compiler, but
> > the multitasker depends on having A5-relative global variables, and
> > I'm having a hard time figuring out how to generate them.
> 
> This has been quite common practice on the Amiga to generate residentable
> programs and reduce code and relocs size. Actually, the Amiga uses
> A4-relative addressing because A5 is used as a frame pointer and A6 is
> reserved for calling shared library functions through a jump table.

  Correct. The AmigaOS/m68k patches add two additional pic modes (word
  and long sized) and handle these modes at those places where they work
  differently to the normal pic/PIC modes. These mode do only affect data,
  not function calls.

> The Amiga people always enjoied A5-relative addressing with SAS/C
> (formerly known as Lattice C) and Storm C.

  I suppose that should read "A4-relative", shouldn't it?

> Of course smart A5 addressing requires some support in the startup
> code (loading A5 for the first time).

  There is an attribute for doing just that: __saveds__

> Programmers must be careful when mixing code compiled with small-data
> with code using A5 as a general purpose register.

  Yes, that would cause havoc.

> On the Amiga, you'd use the "__loadds" function attribute for callbacks
> and softints.

  __saveds

> > Even the -l option to gas, which is documented as changing the
> > default absolute addressing mode to .w (rather than .l), doesn't
> > seem to work.
> 
> That's not meant to be used to trick the compiler. It's just
> a compatibility option for assembly source written for other
> assemblers.

  The AmigaOS version of GAS 1.38 had a -l switch which forced the gas to
  emit 16bit references for calls to external symbols. 

> > attribute((pcrel)) -> var(%pc)

  For const data in the text section such code should be generated by GAS
  automatically.

  Gunther

Re: "small data" in m68k gcc?

[Richard Henderson]

On Tue, Oct 14, 2003 at 04:02:14PM +0200, Gunther Nikl wrote:
>   Wouldn't it be possible to load the offset into a register and use that
>   one to index into the pic table?

Depends on whether the assembler supports the relocation in
that context.  Otherwise, sure.


r~

Re: "small data" in m68k gcc?

[Bernardo Innocenti]

Gunther Nikl wrote:

>>This has been quite common practice on the Amiga to generate residentable
>>programs and reduce code and relocs size. Actually, the Amiga uses
>>A4-relative addressing because A5 is used as a frame pointer and A6 is
>>reserved for calling shared library functions through a jump table.
> 
>   Correct. The AmigaOS/m68k patches add two additional pic modes (word
>   and long sized) and handle these modes at those places where they work
>   differently to the normal pic/PIC modes. These mode do only affect data,
>   not function calls.

I'd be interested in having that code on the ColdFire too. It's
an opportunity for getting rid of all relocations and generating
smaller binaries.

But I'm afraid most uClinux binaries linked against uClibc
wouldn't fit into 64KB. And if you go for dynamic libraries,
then you need that ID_SHARED_LIBRARY mess :-(


>>On the Amiga, you'd use the "__loadds" function attribute for callbacks
>>and softints.
> 
>   __saveds

Yes, you already know about my memory problems :-)


-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html