MKATZ@A.ISI.EDU (Morris Katz) (04/30/88)
In order to effectively use CScheme on modern multiprocessors there is a real
need to extend its 24 bit address space. In the past I have heard two
suggestions for accomplishing this task.
1) Interprest the 24 bits as a word address (object address) rather than a
byte address, effectively increasing the address space by a factor of 4.
(Unfortunately, this requires repeated shifting of addresses on most
processors.)
2) Steal a type code bit and make it part of the address field.
Neither of these solutions is really satisfactory since even in combination
they do not allow one to address even 4M of memory on each of 64 processors.
Does anyone have any other suggestions? I have been considering doubling the
size of Scheme objects to 8 bytes, the first 4 for the type code and the second
4 for the address. This would obviously be quite wasteful of memory, but at
least it would allow me to use the full 32 bit address space of my processors.
How hard do people think it would be to modify CSchemme for such an object
representation? Someone must have a better solution. This sounds real grim.
Morry Katz
-------shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) (05/02/88)
In article <12394354697.55.MKATZ@A.ISI.EDU> MKATZ@A.ISI.EDU (Morris Katz) writes: >In order to effectively use CScheme on modern multiprocessors there is a real >need to extend its 24 bit address space. There is the Spice Lisp technique of divvying up the address space into areas dedicated to each type, in such a way that they still appear to have tags. There is also BIBOP or BBOP, in which objects of the same type are grouped together on a page (as in Franz or Maclisp or Interlisp). Both techniques would give you a full 32-bit address space, although BBOP may be more practical for multiprocessing. However, I suspect that either of these changes would be far too radical for CScheme, whose coding style and general design/engineering have given MIT a black eye in the Lisp/Scheme community... stan shebs shebs@cs.utah.edu (Yes, it's a harsh assessment, but does accurately reflect both my own experiences in trying to understand CScheme, and a number of other people's feelings as well)
Fischer.pa@XEROX.COM (05/03/88)
Put the type bits at the bottom of the address word. No shift, just mask if needed. Result: larger 'words.' This technique also used in Smalltalk-80, immediates were tagged with low order bit, shifted only when needed. (ron)
jeff@aiva.edinburgh.ac.UK (Jeff Dalton) (05/05/88)
> Date: Wed, 4 May 88 11:12:23 MDT > From: shebs <(Stanley T. Shebs)shebs%defun@edu.utah.cs> > Attempts to optimize the C code implementing a virtual machine. If > you use a virtual machine, you've already lost speedwise; doing > complicated C hacks isn't going to recover much for you. (Presumably > that's the reason for hundreds of C macros that could have been > function calls.) C hacks (if you want to call them that) can make a difference, particularly (on many machines) if they let you avoid procedure calls (slow call instructions, parameters moved from registers to stack and back). In-line procedures would be better than C macros, but C doesn't have them.
gls@THINK.COM (05/05/88)
Date: Wed, 4 May 88 03:47:10 edt From: cph@kleph.ai.mit.edu (Chris Hanson) Reply-To: cph@zurich.ai.mit.edu * We have virtually no documentation. This is obviously a terrible thing, and we are in fact generating some. But the bottom line for this is simply lack of time, plus the fact that none of us has much text writing experience. I have not seen the code for CScheme, and did not particularly want to jump into the middle of this flame, but I have a set of points to make about documentation in general, as one who has written a lot of a code for publication and also a lot of text. (1) The way you get experience at writing text is to write text. (When you first started programming you didn't have much experience at programming, either, but you obviously didn't let *that* stop you.) (2) Lack of documentation often stems from the belief that the code is so clear to you (because you've got it all in your head) that you'll have no trouble remembering what's going on six months from now. This belief is invariably false. Even if you don't want to write documentation for other people, write it for the you of six months from now, becase by then you'll be a different person too. (3) Writing documentation usually *saves* time in the programming process, because it takes less time to review design decisions and rediscover how little details work. (4) The writing of documentation actually *improves* the code. The reason is that it is usually easier to clean up a crock than to have to explain it. I have seen this phenomenon hundreds of times in programs of all kinds. I'm not saying that everyone should write documentation the way Knuth did for TeX. I am saying that documentation has a direct intrinsic value to the programming process, and that lack of experience in no excuse. --Best regards, Guy