Miscellaneous Operating Systems/Hardware

hahaha joystick??


love to hear more

I think hamei's comment was apropos "intellectual masturbation". (sorry for explaining the joke.) there are a lot of pie-in-the-sky hardware and OS projects, but some exotic stuff is actually very interesting. To expand on it a little: computer architecture as it's been practiced has been focused on executing instructions as fast as possible from a single stream. The hardware area on a modern CPU that actually does computation is a very small part, about 10-20%. All the rest of the gates are doing ancillary functions to help keep that pipeline busy (caches, prefetch, decoder, dispatcher, speculative execution, multiport register file, TLB, rename registers, branch prediction, etc). But the problem is that all that complexity is what's keeping core speeds stalled for the past decade at the 3 GHz line, while the amount of parallelism exposed by the CPU is also stalled at around 8 threads. Putting more parallel units on a die is hard both because the cores are so large with so much extra stuff, but also because each additional core creates more contention for shared resources like memory, and creates more cache-coherency traffic. We call it the "von Neumann machine model", but the concept is actually at least as old as Charles Babbage with his separate "Mill" and "Store". Anyway this is getting long but basically we should all be using transputers or something else that scales cpu and memory together without shared resource limits.

geo: it's a little misleading to talk about "lisp machines" as a descriptive category since there were different kinds of designs. all of the extant designs take your approach #2. Really, #1 and #2 are the same strategy because they involve defining a virtual machine. You could start with the virtual machine used by an existing compiler, like CLISP, and make adjustments based on the ease or difficulty of implementing all of its features. But you need a VM that can run "without a net": there cannot be any support routines that run underneath the VM, so it needs to grow additional abilities, like virtual memory management and process control. There would then be hooks from the hardware side back into service code running on the VM to handle those tasks.

Had no problem with your calling Lisp Machine fans "dreamers" - after all, once upon a time I'd dreamed myself of owning an SGI box. Alas, a couple of their boxes later I sure discovered they were not at all the "dream machines" I'd dreamed about before.

But I raised an eyebrow upon your calling them "crackpots". Am not sure RMS would approve...

hahaha thanks im bit slow lately, maybe bcoz my "wisdom tooth" were removed?

hmm ok, 1 and 2 are indeed the ideal way.. and i need a VM to have temporary dev environment hmmm ok will dig more btw how about #3, is it not possible to design a processor that reads and understand Lisp syntax without compiling it to a lower level? i think tihs would be cool right? it just like a computer talking to our language, not us talking to them hehe

hi oskar if you want a Symbolics, i found this guy and he want to give his 3600 a good home, and still got others he accepts trade and even just beer hehe check this out: http://www.asl.dsl.pipex.com/symbolics/index.html

and he is near your location than me

The power of Madison Avenue .... I guess I'm lucky. I never dreamed of owning an SGI. OS/2 didn't have any CAD applications so I needed to go somewhere that did. The Indigo loooked suitable. It turned out to be even better than suitable.

No Madison Avenue = no silly fantasies of the Ultimate Ground of Being = no corporate control over a pointless vacuous life driven by ... what ? dreams of glory, conquest, a monstrous irresistible dick ?

I'm still here, while the majority of the ex-SGI-lovers are now chasing after the current object of mental masturbation.

Reality seems to be an alien concept these days.

geo: lisp interpreters need to use a lot of temporary storage for maintaining the 'environment' and evaluating subexpressions. The #3 approach is doable, (I believe SCHEME79 from MIT did this) but you miss out on a lot of optimizations that a compiled order-code can give you: like turning access to a local variable, which is a linear search in an interpreter (ASSOC), into an indexed load from a base register.
There's also something to be said for not locking the semantics of the language too deeply into the hardware design, because languages evolve with new features (like new number types, logic variables, new array types, etc).
Of course you can still have an interpreter, but it will run faster when compiled than interpreting itself :)

hi robe! ok2 got your point thanks! compiler it is then hehe btw todays LISP compiler, are they generating machine codes specific on what machine they are running? or are they generating bytecodes that are still to be run on a virtual machine like java?

Some generate native code only, some generate a bytecode, others can do both. If you define a function and then (DISASSEMBLE 'my-function) you can see the instructions that the compiler generated for it (or for any predefined function).

For example: CLISP doesn't have a native code compiler, it always generates bytecode. This makes it one of the most portable implementations. ECL generates chunks of C code and then runs them through the C compiler and 'dl_load's them into the environment. There was a family of implementations that do that, beginning with Kyoto Common Lisp from the mid 1980s.

Allegro CL, LispWorks, Clozure, and SBCL only generate native code. CMUCL has both bytecode and native compilers.

ah i see, ok all are noted, thanks for the clarifications i think CLISP is the way to go.. hmm is it possible to implement the bytecode virtual machine on hardware? or is this what the LISPM was, a harwdare that interprets bytecodes?

@geo: thanks for the link - will check it out [and I might be willing to offer a bottle of Highland Park in lieu of beer]

hehe we already exchange emails.. hope you can get the 3600! he wants it to have a new home for free and note, he loves photography? so i guess you two will get along hehe one of his barter whish list are some Nikon lens or something so.. for the beer? i offered him our local tsingtao.. or my fave san Miguel but your HP sounds mouth watering! ok let us know your Symbolic goes, yours is more realistic coz your location is near than mine anyway lets see then, prost!!

PowerPC, he asked hopefully?

I don't think the PPC64 port ever worked.

geo: while there can be some overlap, bytecode is usually designed so it will be easy for software to decode, whereas lisp machine instructions were meant to be decoded by hardware (*) and those criteria lead to differing instruction sets. For example, a hardware decoder is easier to build if the fields of different instruction types are aligned, since the same paths of the mux can be used. Symbolics used a fixed instruction width of 16 or 17 bits with essentially a single instruction field format, and around 10 special addressing modes. They had properties in common with both RISC and CISC designs; the instruction fields were fixed length, and their addressing modes were fixed per opcode; but after the hardware decoded the fields, it jumped to a microstore address where microcode performed the instruction. Most instructions used 1 to 2 microinstructions.

* Actually the MIT CONS/CADR machines decoded their instructions using microcode, and had writable microstore. So the machine was originally designed to be a flexible microengine that could run PDP11, Data General NOVA, or other kinds of instructions. The microcode even had the ability to modify itself.

Oskar45: The 3600 is a real beast, it makes a predator rack look cute. Total weight including 14" disks, up to 800 lbs... There is a turbine inside for cooling that could probably amputate a whole hand.
About a decade ago I was visiting MIT and saw one that was left in a courtyard for the scrappers. Leaving aside the lisp machine pixie dust, it is a very strange machine. (The L-machine series have a service processor called a FEP, which is a mc68000 that has access to the data paths of the main processor. One of the 18" [hex unibus sized] boards has the FEP and its memory and bus logic. But the 3600 has an ADDITIONAL controller called a nanoFEP that was made from an 8080 and squirreled away inside the top of the chassis. There is an LED character-matrix display and buttons marked "NO" and "YES" that are connected to the nanoFEP and control the power-on process. The machine could also be controlled entirely by a remote engineer dialed in to its build-in modem when the key was in the "REMOTE" position.)

I object to that. The Predator rack is cute, period.

Can't wait till the wiring of my new room is done, then I'll fire it up again

oh! thats what i thought so thanks for this confirmation so lisp machine instrucion is way to go, will conitnue read that document from MIT and see how to implement it using todays tech

hmmm is it possible to remove the machine instruction code layer? what if the compiler will output the microcode? oh! its because its not changeble right? coz its stored on a ROM geeez but would be nice right? if the compiler will generate microcodes then store it on Flash then from there it will be executed by the processor?

thats super! hehe

geo: You're quick. In fact, MIT Lisp Machine Lisp does have a microcode compiler, that can compile lisp functions to microcode, where the hope is that they will run faster. Problems: microstore is very expensive, think L1 instruction cache, except in a dedicated memory that can't be reused. So there typically isn't much space there (MIT CADR was unusual in that it had a huge microstore, something like 16Kwords IIRC). Also, microcode is where traps (exceptions) are handled, so any function compiled to microcode cannot trap. This is a particular problem in a lisp machine, because in addition to things like page faults, memory references trap in many ways (type tags and invisible forwarding pointers). It must also be very careful about subroutine calls, because since the microstore is inside the CPU, any call stack is a dedicated CPU resource with a fixed depth. If microcode calls nest too deeply the machine crashes. So much for dynamic programming...

With the 3600, Symbolics moved hundreds of low-level functions out of microcode, into regular macrocode, where they ran faster, for all the above reasons. I don't think a microcode compiler was written for the 3600, but of course there was a Lisp-syntax macro assembler that made writing the microcode simpler. A single line of microcode could pop arguments from the stack, check their tags, perform an arithmetic or logical operation, shift the result, check overflow, store or push it into various places, mark flags, and return—anything that the hardware can do in parallel in one cycle.

Writable microcode (WCS - writable control store) was a feature of some minicomputers in the '70s and '80s. MIT CONS/CADR, Symbolics 3600, Three Rivers PERQ, and a number of DEC machines including the KL10, VAX 11/780, 8800, and even IBM S/370.
http://en.wikipedia.org/wiki/Control_store
While an architecture is young it can be valuable to fix problems in the field. At the end of the '80s the WCS fell out of style. (Today a whole machine can be compiled to FPGA, so there is an opportunity for patches even without microcode.)

Sorry for coming back to your old post. Nevertheless, I'd be still interested to learn more about your universally valid criteria for branding people addicted to Lisp Machines as *dreamers/crackpots* (of course, you would need to subsume such minor figures as McCarthy, Gosper, Greenblatt, Stallman, Boyer, Steele, Weintraub...)...Besides, Forth hasn't totally disappeared yet and I don't know what you had in mind with "some other topics"...

the people you listed are not "addicted to lisp machines". there is a difference between inventing something and idolizing it.

Wrong.

Ergo, if I idolize something I invented it?

If that's the case vast numbers of the fairer sex need to see me for a right-to-use permit.