🚀 go-pugleaf

guy@Auspex.COM (Guy Harris) writes:

>The SVR4 documentation I have indicates that the "sysinfo()" routine
>will, if given the "command" SI_ARCHITECTURE, return "a string
>describing the instruction set architecture of the current system, e.g.,
>'mc68030', 'm32100', or 'i80486'."

>It also hints that said "command" is used by "uname -p" to return the
>"processor type" string.

>Unfortunately, as I read it, that *doesn't* correspond to the ABI to
>which the machine conforms:

Uname -p is inended as the generic processor type, but was not firmly
enough specified to guarantee that.  The MIPS ABI Group Technical
Committee wrestled with this problem for a while, decided that there
simply hadn't been enough standardization on sysinfo (esp. amongst the
members of that group!) and defined a series of extensions to sysinfo
to handle the needs of that ABI.  Comments were submitted (I believe)
to the ABICC (UI's ABI Coordinating Committee), but I don't know the
results.  I'll look into it, however.

>	the same presumably applies to other ABIs for processors for
>	architectures that have acquired new instruction over time.

>A *program* probably doesn't have to care what the ABI is for the
>machine on which it's running - if it's the wrong ABI, it won't run,
>period - but a *script* might care.  In particular, Frame Maker has a
>"fmarch" script that, at least on some platforms, is used to select the
>directory from which executables are to be run.

Programs may care about other issues - what _version_ of the ABI,
for example, or the detailed processor type (for (yuck) licensing
reasons. There's an open can of worms here.

>If, in fact, "uname -p" returns a *detailed* processor type, rather than
>an ABI type, "fmarch" and, conceivably, other scripts will have to know
>all the detailed processor types that support a particular ABI, and may
>thus have to change over time as new instructions are added to
>instruction sets and new processor types are added.

>Perhaps later SVR4.x releases have already done this, but if not:

>	There should be a new SI_ABI "command" for "sysinfo()", that
>	returns a string that indicates the ABI to which a system
>	conforms; for example, it would return "i386", or something such
>	as that, on 80386-based machines, 80486-based machines,
>	Am386-based machines, Cyrix-chip-based machines, Pentium-based
>	machines, etc..

Not done, but not a bad idea...
-- 
Mats Wichmann
Unisoft Corporation
mats@unisoft.com (or mats@netcom.com)

Silly Disclaimer:  speaking only for myself, except when I'm not.