Doing it better 2000-06-08 e ### From Reuben. > 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. Ha-ha-hang on. The Alpha has a defined endianness in the sense that it's big or little endian, and you can find out which from a status register somewhere. sMite is just like that. > 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 do: my specialised motivation is to model processors. > 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. 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). > 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. Got it. Well, I just give the user/designer/programmer some control over the tradeoff. I think that's better than either being completely defined or completely undefined. Indeed, processors are sometimes designed in a parametrised way too (can't think of examples OOTOMH). > 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!). Fine, so build systems with sMite that insist on using sMite-endianness, and converting with external libraries. But I think a better approach is to compile those libraries to sMite too and only enforce the sMite-endianness at a higher level. This gives better reuse. Of course you should always isolate tricky assumptions. e.g. in a Forth compiler written for sMite I would have the normal C@ and C! words to read and write bytes. These would be the only place I'd have to worry about endianness if I factored properly. > 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. I just think I can have my cake and eat it. The nice thing is that if I'm wrong I won't have to change the design, just the restrictions. I probably won't even have to change the implementation! -- http://sc3d.org/rrt/ | wit, n. educated insolence (Aristotle)