home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / bugs / sys5 / 163 next >
Encoding:
Text File  |  1993-01-05  |  2.9 KB  |  68 lines
  1. Newsgroups: comp.bugs.sys5
  2. Path: sparky!uunet!wupost!csus.edu!netcom.com!mats
  3. From: mats@netcom.com (Mats Wichmann)
  4. Subject: Re: Can a script find out, under SVR4, the ABI to which a machine conforms?
  5. Message-ID: <1993Jan5.150047.19932@netcom.com>
  6. Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
  7. References: <16187@auspex-gw.auspex.com>
  8. Date: Tue, 5 Jan 1993 15:00:47 GMT
  9. Lines: 57
  10.  
  11. guy@Auspex.COM (Guy Harris) writes:
  12.  
  13. >The SVR4 documentation I have indicates that the "sysinfo()" routine
  14. >will, if given the "command" SI_ARCHITECTURE, return "a string
  15. >describing the instruction set architecture of the current system, e.g.,
  16. >'mc68030', 'm32100', or 'i80486'."
  17.  
  18. >It also hints that said "command" is used by "uname -p" to return the
  19. >"processor type" string.
  20.  
  21. >Unfortunately, as I read it, that *doesn't* correspond to the ABI to
  22. >which the machine conforms:
  23.  
  24. Uname -p is inended as the generic processor type, but was not firmly
  25. enough specified to guarantee that.  The MIPS ABI Group Technical
  26. Committee wrestled with this problem for a while, decided that there
  27. simply hadn't been enough standardization on sysinfo (esp. amongst the
  28. members of that group!) and defined a series of extensions to sysinfo
  29. to handle the needs of that ABI.  Comments were submitted (I believe)
  30. to the ABICC (UI's ABI Coordinating Committee), but I don't know the
  31. results.  I'll look into it, however.
  32.  
  33. >    the same presumably applies to other ABIs for processors for
  34. >    architectures that have acquired new instruction over time.
  35.  
  36. >A *program* probably doesn't have to care what the ABI is for the
  37. >machine on which it's running - if it's the wrong ABI, it won't run,
  38. >period - but a *script* might care.  In particular, Frame Maker has a
  39. >"fmarch" script that, at least on some platforms, is used to select the
  40. >directory from which executables are to be run.
  41.  
  42. Programs may care about other issues - what _version_ of the ABI,
  43. for example, or the detailed processor type (for (yuck) licensing
  44. reasons. There's an open can of worms here.
  45.  
  46. >If, in fact, "uname -p" returns a *detailed* processor type, rather than
  47. >an ABI type, "fmarch" and, conceivably, other scripts will have to know
  48. >all the detailed processor types that support a particular ABI, and may
  49. >thus have to change over time as new instructions are added to
  50. >instruction sets and new processor types are added.
  51.  
  52. >Perhaps later SVR4.x releases have already done this, but if not:
  53.  
  54. >    There should be a new SI_ABI "command" for "sysinfo()", that
  55. >    returns a string that indicates the ABI to which a system
  56. >    conforms; for example, it would return "i386", or something such
  57. >    as that, on 80386-based machines, 80486-based machines,
  58. >    Am386-based machines, Cyrix-chip-based machines, Pentium-based
  59. >    machines, etc..
  60.  
  61. Not done, but not a bad idea...
  62. -- 
  63. Mats Wichmann
  64. Unisoft Corporation
  65. mats@unisoft.com (or mats@netcom.com)
  66.  
  67. Silly Disclaimer:  speaking only for myself, except when I'm not.
  68.