Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!mit-eddie!godot!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@csnet-relay.arpa From: BostonU SysMgrNewsgroups: net.unix-wizards Subject: Re: integer types, sys calls, and stdio Message-ID: <7242@brl-tgr.ARPA> Date: Fri, 11-Jan-85 20:36:00 EST Article-I.D.: brl-tgr.7242 Posted: Fri Jan 11 20:36:00 1985 Date-Received: Tue, 15-Jan-85 00:44:16 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 61 > From: John Bruner > > Here at the S-1 Project at LLNL we are porting UNIX to our own > machine, the S-1 Mark IIA. The hardware is capable of operating > upon 9-bit, 18-bit, 36-bit, and 72-bit quantities, so we have defined the following types: > > char = 9 bits (S-1 quarterword) > short = 18 bits (S-1 halfword) > int = 36 bits (S-1 singleword) > long = 72 bits (S-1 doubleword) [questions about whether this is the best way to assign these and portability problems] There are really two issues here. The first is re-compiling old code reasonably and a second on how to write new code to best access the hardware. It seems pretty clear that old code will be served well if long means 36-bits as it likely assumes at most 32-bits. The machine was built on the assumption that sometimes people need more than 36b and are willing to pay whatever storage/speed penalties. I presume that means either they are using integers outside of a 2**36 range or bit-packing data (same thing, probably not in practice the problem.) It would be a lie to even imply that such code is at all portable. My suggestion, therefore, is that long==int==36b for backwards and likely forward portability in general and a new type be created for the 72b. (I realize there would still be portability problems, but you do the best you can.) I personally would rather see you code it as built-in functions to your compiler (a la FORTRAN.) This would give at least a glimpse of opportunity to port a program from the S-1 by building a simulator. For example, define routines: store72(result,value) add72(left,right) sub72(left,right) and write expressions sort of like lispisms: store72(lv,add72(v1,v2)) ; etc. Declaration would be by a special name, long72 comes to mind. Your compiler could know these routines and produce the correct instructions (or look at the sed scripts 4.2 uses.) I would probably then typedef long72 before re-compiling your code to be an array of two or three longs on my VAX. This would then pass pointers on my machine. Note that store72 could easily be a macro for 'lv = ....'. This all reminds me of the old V6 compiler which uses things like fmod() [flt pt modulo] and the generation of subroutine calls for 32-bit longs on a PDP11. If you don't care about forward portability, then it doesn't really matter, no? -Barry Shein, Boston University