Hacker News new | ask | show | jobs
by dmitrygr 2006 days ago

  > surely emulating 32-bit
  > instructions from 8-bit
  > doesn't take a thousand
  > cycles on average.
It does if you do it in C, and also need to emulate the mmu and permission checks. Plus arm's instructions do a lot. A free arbitrary 32-bit shift in every instruction is hard on an 8-bit device which can only shift 8 bits by one bit per instruction. You end up with a lot of loops, and loop control instrs kill perf there.

The fact that I had to bit-bang the memory interface also does not help as the avr device has no dram controller

I had, at some point, rewritten the core in avr assembly for a large-ish speedup, but i never got around to publishing it.

Currently i am working on a TTL-built 1-bit computer, unto which i want to port this emulator, so boot linux on a 1-bit computer :)

3 comments

Don't underestimate the 1-bit computer!!

One of the most popular SIMD computers in the late 80s was the CM-2: a 4096x wide 1-bit computer. All SIMD-instructions.

So it can definitely be used "seriously".

> 1-bit computer

I've really enjoyed RISC V serial (SERV) presentation - 1-bit computer essentially. Wonder how low one can get in terms of transistor count, without going the path of LGP-30.

At that point, you probably do just want to go the path of the LGP-30. The registers are the most expensive part. While you could move them into RAM, that has the same performance cost as an accumulator machine, with more control complexity. If you were considering RISC (without compression, anyway) then you're likely not heavily pressed for code density to begin with. It probably could be done in under 100 gates, excluding the shift registers.
Since you are already using TTL parts -- would peripherals build from them (or similar discrete gates with whatever voltage levels you'd need) help to speed up the ARM emulator? I'm asking this because I'm actually not sure if such a thing would be faster than even bit-banging on the AVR. But I could imagine that things like the memory interface would benefit from a "hardware" implementation.
Current plan is no special interfaces. Just 8 input and 8 output pins controllable via special instrs.