RE: shared text, shared libs again

["Howard Chu" <chu@platinum.com>]

I don't like this approach, but perhaps that's only me. While it is
certainly portable,
it is extremely non-optimal. Another part of the motivation behind the
original
mbaserel setup was to get more speed - the word-sized indexing allows both
space
savings and time savings, with position-independence as a side benefit. My
goal has always been to generate the fastest possible code. The approach you
outline will be
twice as slow and twice as memory-hungry as plain old absolute addressing.
No fun,
if you ask me. The simple fact is, within a 32-bit address space, with lots
of
regions masked off for special purposes, you will *never* need a full 32 bit
offset for addressing your program text or data. Why waste that space, and
sacrifice that execution time? The scheme I suggest will handle just about
all programs, making access to simple variables very fast, and slowing down
access to structures by only a tiny amount, with an almost negligible effect
on array accesses. (In both of these cases, the compiler must first load the
address of the structure or array, before manipulating the object. The
usual way to do this with absolute addressing would be e.g.
	lea #array,$a0
a simple 6 byte instruction, which will execute in about 12 cycles on the
68000. This
would be replaced by
	movel Xarray($a4),$a0
which is only 4 bytes, but will cause another 4 bytes to be fetched from
memory, making
it more compact but with a 2 byte access penalty overall compared to the
absolute case.)

-----Original Message-----
From: Jan Paul Schmidt [mailto:Jan.P.Schmidt@mni.fh-giessen.de]

On Thu, 18 Jun 1998, Howard Chu wrote:

> The basic shared text scheme remains as before - all data is referenced
> relative to
> a global pointer in address register a4. This allows up to 64Kbytes to be
> directly
> addressed in a very efficient, position-independent manner. To extend its
> usable
> limits, this data/bss space must be divided into "small data" and "large
> data".
> Large data consists of any arrays or structures that are larger than 4
> bytes. Whenever these things are declared, they go into the "blockdata"
> segment, with only a pointer to
> the blockdata being stored in the "smalldata" segment. (Note that gcc is
> already smart enough to handle arrays & structs of 4 bytes or smaller as
> longwords, so they can still
> be manipulated efficiently.)

Instead of using word references, like it is currently done when using
-mbaserel with gcc, wouldn't it be easier to implement long references
than splitting stuff into a large and small data area? I know, this would
slow things down and extends the size of the executable. By the way, I'm
speaking of 68000 instruction set not 68030. For example:

  move $1234(a4),d0

would become something like

  move #$12345678,d4
  move $0(a4,d4.l),d0

This certainly is a lot longer, but I think when gcc is forced to avoid
using global variables, this won't become noteable. Maybe the execution
time is at the end as fast as absolute adressing. And for 68030 there
could also be the other possibility :o)

Some of you maybe already thought about this years ago when talking
about the -mbaserel feature for gcc, but I was not online at this time :o)

> Anyone else have ideas on making this all work?

A complete port of the binutils?

If you are working on the linker, I suggest, you take the latest source
from tu-harburg and speak with Guido Flohr, who also is working on the
linker.

jps