[LMH] Ooh, look! List traffic!
Fri Mar 5 04:30:01 2004
Dear Mr. Banffy
Somewhat old-fashionedly, the mailing list is set up so that if you hit=20=
the reply button in your email client, it replies to the sender, not to=20=
the mailing list. This behavior is a near-religious issue with some=20
mailing list administrators that you probably don't want to touch, but=20=
for the time being, you should probably use reply-all. I sometimes=20
forget, too. While I'm at it, let me comment on your message.
On 5 Mar 2004, at 03:15, Ricardo L. A. B=E1nffy wrote:
> It can't be that hard to emulate a decades-old architecture (late=20
> 80's? 90's? - I remember reading about them at my college library) on=20=
> a couple gigahertz current processor. I know the architecture was far=20=
> more complex than an ordinary desktop computer of that time (and=20
> probably is now), but I doubt it is beyond the reach of a modern=20
Being somewhat of a bookworm, I'm always interested in written matters;=20=
what was it you found about Lisp machines in your college library?
> I remember my Pentium something (in Portuguese we call them Lentiums,=20=
> which is not funny in English) could emulate a 68K Macintosh about=20
> twice as fast as a 68K Macintosh could emulate itself. There weren't=20=
> more than 5 years between the two computers.
Hmm... the joke *is* funny in French. At any rate, you are completely=20
right in this observation.
> IIRC, OpenGenera did just that - emulation atop an Alpha. If an Alpha=20=
> can do it, a Pentium 4 HT or a PowerPC 970 can.
Yes, although OpenGenera *was* extremely well-bummed for speed. It was=20=
written in straight alpha assembly, with a Lisp-based macro layer on=20
top, and the programmers took great care to lay out the segments of=20
code in such a way as to minimize cache misses. The crucial trick is=20
that the alpha's L1 cache was fast enough that it could practically=20
function as a microcode store, so that if you kept the simulator in=20
cache at all times, you would loose relatively little performance. That=20=
said, time heals all wounds, and Moore's law certainly does, so I=20
wouldn't be surprised if you could do the same thing in a high-level=20
language just fine given a 970 (a.k.a. G5).
> Implementing an emulator in software ("C" seems an obvious choice=20
> because of performance and portability, if not elegance) would also be=20=
> a nice starting point to any hardware implementations. At least, if=20
> well written (as in "human-readable"), it could serve as a reference=20=
> to what, exactly, the hardware should be doing.
Sure; programming, as Sussman likes to say, is a way of expressing=20
ideas as much as a way to tell a computer what to do. (I hope I'm=20
quoting this right at 5 in the morning.)
> If we are really serious about doing it, the rights to the software=20
> must also be sorted out. How generous are their owners?
As I remember, but others know this much better than I do, TI (or=20
whoever bought them) doesn't want to admit that they own the=20
intellectual property to anything Exploder-related without consulting=20
their lawyers, for which you'd have to pay them money. The consensus at=20=
the time was to not deal with legal issues until anyone is approaching=20=
a working emulator.
> We would also need functioning hardware to validate the emulator=20
> against. Can it be provided?
I think some people on the list have running TI hardware.
> As Alastair pointed out, it is a big, hard and scary thing to do,=20
> until actually doing it proves us wrong.
Yes, and the main problem seems to be finding out the details of how=20
the system worked. If the project were to write an emulator for a=20
machine that was completely specified, the project would probably be=20
much further by now; unfortunately the brave hackers that have worked=20
on it so far seem to have to spend a lot of time reverse-engineering.
> Jaap Weel wrote:
>> I'm trying to get into the whole FPGA thing because I'm supposed to=20=
>> implement a CPU in one for my summer job. There have been various=20
>> reports from people doing interesting projects in surprisingly little=20=
>> time given the right tools; look up fpgacpu.org for some pointers and=20=
>> lots of FPGA shop talk. Especially his circuit cellar article gives a=20=
>> good idea of the practicalities involved, I think. Once again, he's=20=
>> doing RISC-like hardwired control, not microcoded control. I don't=20
>> know if anyone has tried microcoded control yet.
Jaap Weel Campus address: | dorm (626) 795-9748
Caltech, Blacker '05 Caltech MSC #874, Pasadena, CA 91126, U.S.A.
www.its.caltech.edu/~weel Permanent address: | home +31-46-4337033
E-mail: firstname.lastname@example.org Kelderstraat 2-4, 6171 GB Stein, Netherlands