Doing it better 2000-06-08 h
###

> > Eh? What defines the endianness, then? (Yes, this is just like sMite -
> > endianness is not defined except in terms of the semantics of the
> > byte-access instructions). Is the status register really telling you the
> > endianness of the network card (the only device which accesses bytes)?
>
> No, it's generally OS-dependent. The OS decides which endianness it wants,
> and the chip is configured by having a signal sent to the right pin (in
> theory it could be software controlled, I suppose).

My question was not 'who chooses the endianness?' but 'what defines the
endianness?'. For example, which byte of the physical memory is address 0?

> > > Both. But it's only a basis for Tau for raw code execution. e.g. it's not
> > > the same sort of thing as MIN; you could easily implement MIN in
> > > sMite. It *is* the same sort of thing as an x86 or Alpha, or Cintcode,
> > > i.e. a code target. It's just that, unlike the real chips, but like
> > > Cintcode, it provides binary portability (at a low level, and in ways
> > > which you can violate).
> >
> > I have to object that binaries are not portable between sMite and
> > Cintcode. I know what you mean, but your analogy is confused.
>
> My analogy isn't confused. sMite is the same sort of thing as
> Cintcode. Cintcode provides binary portability; so does sMite. I'm not
> providing binary portability between different processors (e.g. x86 and
> Alpha) as that's impossible by the definition of their instruction sets.

Yes, but sMite and Cintcode are themselves processors, and they have
encodings, and their encodings are not the same. You drew an analogy
between x86 and Alpha and sMite and Cintcode. Code for any of these does
not run on any of the others without some sort of emulator or
translator. I'm just being pedantic, of course: I'm quite aware that
translating sMite into x86 is much, much easier than, say, translating
Alpha into x86.

> > Now I've got it too. You have two languages, one of which is like C, and
> > one of which is like a processor. They are extremely similar, and both
> > called sMite, except that one has muddy semantics, and the other has a
> > couple of extra restrictions.
>
> Sigh.
>
> > That assumes you want to compile Forth to the muddier version of sMite.
>
> Yes.

continues as if you had said no...

> I was thinking of Beetle, where C@ and C! were always little-endian,
> so that the memory image (of my Forth compiler) could be loaded big or
> little endian, and strings would still be right.
>
> Suppose you have the string:
>
> GOODBYE
>
> Then on a 32-bit little-endian architecture it will be loaded as
>
> 01234567
> GOODBYE
>
> and on a 32-bit big-ender:
>
> 32107654
> GOODBYE
>
> However, on a big-ender, C@ and C! flip the bottom two bits of the
> address, hence mapping little-ender byte addresses to big-ender addresses.
>
> This is compensating after the fact for the data having been reversed. In
> sMite no automatic translation is done, so you have to compensate
> manually.

You are still assuming that the bytes might get reversed by being saved to
disk and then reloaded on another computer. In a sensible sMite platform,
it would be words that are saved to disk, and there would be no problem.

Here's my version of your example:

0   1
GOODBYE

You get four characters packed into an integer at each address. You
can pack them in any way you want, all written in completely portable
sMite code.

The difference between the two languages ('sigh' indeed!) is that in the
C-like language you see endianness as a language-design problem, and in
the CPU-like langauge you see it as a library-design problem. In Beetle,
you fixed the byte-load and byte-store instructions rather than the
hard-disk but it's basically the same approach: the programmer sees a
portably defined abstract machine.

I think we agree with each other, but you keep telling me we don't. Am I
missing something?

Alistair