Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ncar!gatech!mcnc!decvax!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: ABIs and the futurrrr of UNIX(tm)
Message-ID: <7584@ncoast.UUCP>
Date: 5 Apr 88 01:40:28 GMT
References: <431@micropen> <1697@van-bc.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 41

As quoted from <1697@van-bc.UUCP> by sl@van-bc.UUCP (pri=-10 Stuart Lynne):
+---------------
| PS. I'm not a Cobol person, but I have dim memories of a product blurb for
| one of the more popular Cobol compilers doing something along these lines as
| well. Cobol to object code which could be interpreted on any of the
| supported systems.
+---------------

Ryan-McFarland's RM/COBOL just about does this; you can *cross-compile* to
any machine from any machine, but they couldn't go to one single format
because the original format depended on byte ordering.  They could deal with
just about everything at this point, at the expense of losing upward com-
patibility with old programs; they may have done it with Cobol-85, I don't
know.

(For those interested, nitty-gritty details follow.)

The RM/COBOL compiler supports 4 flags controlling cross-compilation:

* byte ordering
* object record size 254 vs. 256 bytes (this one has TRSDOS written all over
	it! -- especially since the manual says "Z80 systems only")
* ASCII vs. EBCDIC
* inhibit new features of compiler (the compiler that permits cross-compiling
	is upward compatible with the old one, setting this flag turns off
	the new commands)

The only one that is relevant that *can't* be dealt with at runtime is ASCII
vs. EBCDIC -- and even that one could be if the first block of the runtime
were a character translation table.  The 254-vs.-256 distinction could be
dropped; who uses a TRS-80 Model I/III these days?  And it doesn't apply to
the later RM/COBOL versions (2.x) anyway, so Model IV wouldn't be affected.
Byte ordering, of course, is arbitrary in an interpreted system.  The disable-
new-features one simply flags as errors any V2 code, since the V1 executive
doesnt know the interpreter opcodes for the commands added in V2; not relevant
here.

If interpreters were faster (or threaded interpreters were easier for humans
to program), hardware independence would be trivial.
-- 
	      Brandon S. Allbery, moderator of comp.sources.misc
       {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery