[LMH] Ooh, look! List traffic!

[Jaap Weel]

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.

	/jaap

On 5 Mar 2004, at 03:15, Ricardo L. A. B=E1nffy wrote:

> Gentlemen,
>
> 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
> processor.
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.
>
>
>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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: weel@caltech.edu    Kelderstraat 2-4, 6171 GB Stein, Netherlands
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D