Re: more gcc/mintlib questions

[hyc@troy.la.platsol.com (Howard Chu)]

  On Wed, 11 Mar 1998, Howard Chu wrote:

  > We might consider just single-character tokens for 16 bit int and 68020,
  > e.g. 's' for short int, and '2' for 68020 libs. I'm also thinking about
  > putting these in the suffix, instead of the filename, e.g.
  > 	c.a, c.as, c.a2, c.as2

  It occurs to me to wonder why we're trying to encode all this information
  in the filename itself.    My first instinct would be to put it in the path
  name:

  	libc.a
  	mshort/libc.a
  	m68020/libc.a
  	m68020/mshort/libc.a

That was my first instinct as well (dropping off the redundant "lib" prefix
though). It's just that I've often run afoul of problems with this sort of
scheme, where the filename itself doesn't carry enough information to fully
define its content. If someone moves your file to the wrong directory by
accident, you will never be able to identify the problem. However, it does
have the advantage of keeping the number of entries in a directory down to
a managable size. Perhaps a combined approach, just like terminfo uses - use
both a unique filename *and* a directory hierarchy. Also, I have a preference
for very short pathnames...

The idea of making the linker smart enough to pick substitute libraries is
appealing, but can be problematic. Most of the variables are mutually
exclusive - shortint cannot be mixed with longint, baserel cannot be mixed
with absolute. 680x0 variations are generally safe *except* for 68020+ vs
68000 - 68000 libs use gcc-internal library calls for 4-byte arithmetic,
68020+ uses regular instructions. So if you have a mostly 68020 link, but
at one point fall back to a 68000 object library, you may wind up with
missing symbols that the 68000 object required.

There is also a question of -m68881 co-proc vs 68881 peripheral vs soft-float,
etc., but I think that is best solved by a runtime FPU emulator that always
does the right thing. (I.e., if it detects a real FPU coproc, it does nothing.
If it detects a peripheral, it installs a line-F handler that knows how to
talk to the FPU in peripheral mode. If it detects nothing, it installs itself
as a full software FPU emulator. It ought to also include 68000 vs 68020-
specific variants of its emulation code. This can be written as a standalone
TSR, but for best performance on MiNT would need to be integrated into MiNT's
context-switch management. I suppose it ought to also take care of 68040 and
68060 unimplemented FPU instructions...)

Assuming we can define some precedence rules for how the linker can
legitimately substitute, this could work very well. (And obviously the
68020+ vs 68000 problem can be solved by including the missing functions
in the 68020 libc, with 68020 instructions implementing the functions...)
I guess the only allowable substitutions are on the CPU version chain:
	68060 -> 68000
The baserel vs absolute and short vs long are completely orthogonal.

It strikes me that the user-mode changes from 68020 to 68060 are almost
nonexistent, excluding FPU issues. Who really needs 68060-specific libc?
  -- Howard