🚀 go-pugleaf

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:

	there isn't a Motorola 68030 ABI - there's a Motorola 68K ABI,
	but machines with 68020's, 68030's, or 68040's all have the
	right instruction set for the 68K ABI;

	similarly, there isn't an Intel 486 ABI- there's an Intel i386
	ABI, but machines with 386's, 486's, or presumably
	586's^H^H^H^H^HPentia have the right instruction set for the
	i386 ABI, or simulate the missing instructions in software, e.g. 
	if the floating-point unit is missing;

	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.

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..

	The string returned by SI_ABI for a particular ABI should be
	part of the ABI specification.

	There should be a "-b" flag to "uname" to write the string
	returned by SI_ABI to the standard output.