Path: utzoo!mnetor!uunet!husc6!m2c!ulowell!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo Press Release: Domain/OS
Message-ID: <3ae91d3a.13422@apollo.uucp>
Date: 17 Mar 88 17:53:00 GMT
References: <3a60e1e6.8cd8@apollo.uucp> <460@edsews.EDS.COM> <156@vader.UUCP> <1060@qiclab.UUCP>
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 63

In article <1060@qiclab.UUCP> neighorn@qiclab.UUCP (Steve Neighorn) writes:
>On page 3 of the magazine, Mr. Schwartz writes:
>
>"The Domain 10000's are object code-compatible with Apollo's existing
> workstation family. However, source code running on current Apollo
> machines must be recompiled to run on the new faster systems, a job
> that Apollo officials said requires some work.
>
>I will publicly apologize if I am missing the "big picture" here, but
>how can the 10000 be object code compatible with current machines at the
>same time source code running (?) on current machines requires 'some
>work' to be recompiled?

Someone pretty clearly lost a "not" here.  The DN10000 (quick: did I
get the number of zeros right?) is NOT object-code compatible with Apollo's
680x0 machines.  We did try hard to remain DATA compatible the 680x0
machines.  Not surprisingly, the 10000 is a big-endian machine and uses
IEEE floating point.  (Oh yeah, we decided to stick with ASCII too :-)

A more insidious issue in the RISC arena is data alignment.  RISC machines
really want data to be naturally aligned; i.e. that N byte quantities
start on memory locations that are 0 MOD N.  Consider a program that
writes out a file of structs of the form:

    struct s {
        short foo;      /* 16 bits */
        long bar;       /* 32 bits */
    }

(I mean "write(fd, v, sizeof v)" where "s" is a "struct s".)  Fortran
programmers do the equivalent sort of thing ALL the time.  Believe me.

It seems like it'd be nice in these days of distributed file systems
if you could read back that data on another machine made by the same
vendor using a program compiled from the exact same source.  Most (I
think) 680x0 compilers lay out this struct as 6 bytes.  Many RISC compilers
would be tempted to lay it out as 8 bytes (with a two-byte hole between
"foo" and "bar") to get the long to be naturally aligned.  We chose to
make the DN10000 compilers by default use the 680x0 data alignment rules
to make sure that a binary file written on a DN4000 could be read on
a DN10000.  Of course, there's a price (the 10000 will access the data
slower than it otherwise would have) but no one said compatibility came
cheap.  Of course, the 10000 compilers will tell you (if you don't tell
them not to) about all the cases where they're unhappy about how the
alignment is working out, and you can tell them to override the default
alignment rules and use natural alignment if you're not worried about
these data compatibility issues.

A variant of this case is where you pass a pointer to procedure that's
expecting a (say) "long *" but you passed "&v.bar" as the parameter.  In
this case, the compiler can't know that you might have done this.  It
assumes that the argument is a pointer to a naturally aligned long and
compiles the code accordingly.  However, at runtime, a hardware trap
will occur (the equivalent of "odd address error" on a 680x0) and software
will automatically figure out what happened and cough up the right data.
The cost of this feature is even higher than cost of the feature
described above.  But it works (and you can fix your code if you want
to).
-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {decvax,mit-eddie,umix}!apollo!mishkin