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

> > ...because it has a defined endianness.
>
> Correct.

but sMite doesn't. So the analogy with the Alpha doesn't hold. And sMite
finds it difficult to access bytes in a portable way.

> > For a C program to read data from a MIN program, you either have to do
> > some work in MIN to make sure everything is properly evaluated the way
> > the C program likes it, or you have to reimplement much of MIN in C,
> > including (in a pathological case in which the data is a lazy result
> > of a program that has not yet been compiled) the dynamic compiler.
> > However, I'd still call both C and MIN universal languages, because
> > each of their favourite data models is suitable for just about every
> > application.
>
> I'm not really considering cases where data is represented as code.

I know: you're thinking of C. I was just pointing out that the world you
inhabit is by no means the only one. In fact, it isn't even a very big
one, and it is shrinking at the moment. Even C++ represents data as code.
To worry about low-level access to memory, you have to have a really quite
specialised motivation, and I think you need to make sure that you do and
that you understand that you do.

I'm still not quite sure whether you do see sMite as a utility to be
called from C, or as the basis for Tau, which is why I asked for a
paragraph about your motivation.

> > Sorry, I used confusing words. You are allowing C programs to perform
> > dynamic compilation, but not necessarily using C as the source language. I
> > think of the source language as an excercise in understanding humans that
> > has nothing to do with code generation.
>
> I've not got a source language (other than assembly).

Which is why I thought you'd understand.

> > Do you think you could write a paragraph explaining exactly what sMite is
> > for, from which it follows that your best option is to muddy the semantics
> > in order to provide a more 'raw' interface to memory, and therefore to
> > make it easier to inter-work with languages like C? When you talked about
> > universality and such like I didn't get the same picture that you seem to
> > have.
>
> I'm not muddying anything (unless you call placing a slight restriction on
> the way words are stored in memory "muddying").
>
> sMite is a virtual machine that provides a portable execution environment
> at the same level as a conventional CPU.

You are muddying the semantics every time you mention bytes or word
widths. These considerations allow you to write code whose behaviour is
different on different platforms. A conventional CPU is at a lower level
than this: it completely specifies the semantics, or at least makes it
absolutely clear where they are undefined.

If you have to worry about whether a pointer is to a sMite-endian or
native-endian word, you will never get such a clear distinction (it could
be undecideable whether the semantics is defined!). Superficial syntax
aside, it is precisely this sort of programmer-beware approach which makes
C a higher-level language than machine code (by which I mean more
abstract, not easier to write!).

If you want something that is like a CPU, but which is portable, then I
think you are forced to choose a word width, and either to abandon any
concept of the address of part of a word (such as a byte), or to define an
endianness.

Maybe you don't really want something that is like a CPU, though. Maybe
you want something that is like C. Motivation crises R us.

Alistair