flaps@dgp.toronto.edu (Alan J Rosenthal) (10/19/89)
diamond@csl.sony.co.jp (Norman Diamond) writes: >Whether there was a reason or not, IBM once built one. Well, ints and >floats were unrestricted, but instructions were addressed by even >addresses and strings were addressed by odd addresses. True, you >couldn't put C on it. First of all, there may be many reasons for not using the native string operations of a cpu. Possibly they are length-counted, or terminated with something other than zero. Another possibility may be that they can't start on an arbitrary byte address as in your example; thus, if `s' is a positive-length string, precluding `s+1'. Since there is no way to mix function pointers and non-function pointers, off hand it looks like the other alignment restriction you mention would not cause difficulty. Nevertheless, one can imagine a bizarre cpu where, for example, ints are two bytes the first of which must be on an even address, and floats are two bytes the first of which must be on an odd address. I claim that C is still implementable on that machine. Make sizeof(int) == 2 and sizeof(float) == 4, and make the conversion (cast, etc) from pointer-to-int to pointer-to-float add one (char-sized) to the pointer, and make the conversion from pointer-to-float to pointer-to-int subtract one from the pointer. Make pointer-to-char the same format (so to speak) as pointer-to-int, so that malloc() returns an even address. Alternatively, this plus-one stuff could be hidden in pointer-to-float dereferencing. True, this wastes lots of space, which in the case of things like large arrays of floats you wouldn't have to waste in fortran or assembler. ajr