Miscellaneous Operating Systems/Hardware

hi robe! sorry was busy again.. but i read your post already and did more research on your comments and all are becoming clear now, really thanks for all this info hmm all this sounds CISC like right? When i try to search a RISC LISP CPU, i saw someone implemented it but not sure it got done hmm

btw, just finished watch the video on Kalman Reti's talk at Boston last year? wow!!! watching the demo using VLM, i cannot believe what i saw! all those cool features already done on an 80's machine? my God.. and i think even some of those features are not available on todays OS right? why so? is it because of the C language barrier? or are just developers lazy to implement such cool feature? esp this one: you can change the code even the program is running, then just recompile it, tada!! how i wish Lisp machine will return and taking advantage on todays hardware techs..

today, also planned to use Lisp for one of my task, parsing a big data files? hehe coz of urgency, i just picked my strength.. C even faster for me with C#, but neh, just want to try C again on PC's.. tired of always C on embedded field hehe

sorry but still cannot resist on dreaming to own a real Lisp machine.. how's your Oskar? did you made the deal? me, still asking Ian's help how to ship it here hehe but very slim chance why does all the cool stuff always not on my side

In some ways yes, in some ways no. "Classic CISC" like the Motorola 68020, NS32016, or VAX have variable-length instructions with "operand descriptors": After loading and decoding the first instruction word containing the opcode, the CPU may need to fetch and decode several more words of the instruction to know how to supply the operands. So a single opcode may need several microcode branches to resolve all the operand possibilities. For example, a 68020 instruction can have multiple operands, each of which employs a series of operand descriptors, with memory addresses calculated from pointers which are themselves loaded from memory. 68k instructions can be as short as 16 bits or as long as 176 bits.

VAX is more complex, with many 4- and 6-operand instructions and very complicated addressing modes. It is "orthogonal", which means that every operand can use any address mode, including the deferred addressing modes that indirect through memory. The longest VAX instruction is 448 bits long, except for a class of instructions like CASEW that are actually of unlimited length (limited by the machine's 4GB address space). Just the ADD opcode has over 30,000 addressing mode combinations.

A closer comparison could be made between a lisp machine like the 3600 and the PDP-10. They both have fixed-length instruction encodings with very few addressing modes. Both are word-addressed, with all operations done on 36-bit words. Both have at most one operand in memory, like many RISC machines. But both also have the property that an operand loaded from main memory may immediately redirect to somewhere else in memory, or not: invisible forwarding pointers. The PDP-10 has been called the "first lisp machine" because of this property and some properties of its operating systems.

Overall, I think that the instruction sets of lisp machines are not Complex, they are just unfamiliar. They have a lot in common with old Burroughs mainframes like the B5000: most operations take place on a stack, the top of which the CPU keeps in registers for fast access. They also are object-oriented: compiled code basically never addresses memory directly, instead relying on the CPU to supply subsidiary objects to it. So it has instructions that look like Lisp functions: CDR, RPLACA, AREF. The benefit of that is that even if the code has bugs (it always does), it is impossible for it to reach or modify objects inaccessible to it through the supplied primitives. For example, array access is always bounds-checked, and the size of the datum returned is under the control of the array, not the compiled function. So no matter what, when we access an array we can only get out of it the elements that are its proper members.



You're right again, the real valuable stuff is/was the software environment and what it made possible. One of the reasons Symbolics went bankrupt [is that they made bad real estate investments before the Black Monday in 1987...] is that too much resources were put into special hardware products, that didn't have the economies of scale of their competitors. The VLM shows that the system could have run on "commodity hardware" (is AXP really a commodity? I don't know) using a virtual machine layer. VLM was faster than all Symbolics hardware even run on slow 200 MHz Alphas.

Today's Common Lisp environments do have debugging and recompiling during runtime, but some advanced Genera features (like its transparent file access, editor, and error recovery) are hard to reimplement in a way that is compatible with the underlying operating systems.

hi robes! wow! all you said here are true coz these days im digging about Lispm and all very educational, even now i can imagine how difficult to desing CPU architectures hehe really had fun reading.. esp the history? About the two group at MIT AI lab and RMS at the middle? hehe really interesting people too.. anyway thanks again for confirming all this info, ill just keep reading and keep dreaming for a Lispm revival hehe hunting for a good FPGA for starter now..

hehe reminds me of a nice VMS joke.. the point to the joke was the reason why that black monday happend was because they use IBM instead of the VMS

If you have time to kill, I immediately remembered this old chestnut: VAXen, my children, just don't belong some places

"... they have several large herds of VAXen..."
"He had a young apprentice gnome who was about 65."
"``Great, now we can have 24 hour video tapes of the operators eating Chinese takeout on the CPU.''"

hahaha yes2!! its this one hehe thanks for finidng this back smj, really funny story