Hacker News Reader

Comment by slacka | Hacker News Reader

> It was based on the company's CRISP (C-language Reduced Instruction Set Processor) design. CRISP and Hobbit were optimized for running the C programming language.

Couldn't the same be said of any modern CPU short of the Java processors that have mostly failed?

View on HN

I took a university assembly language course (UIUC CS225) on the WE32100, which was the predecessor to the Hobbit. We worked on a stack of AT&T 3B2s donated to the college.

I distinctly remember the STRCPY opcode, which did exactly what you expected it to do.

https://imgur.com/a/auZlxwG

I have fond memories of that instruction set, but looking back now it's like looking at a loaded weapon.

The WE32100 was very emphatically not-RISC, much more VAXish if anything with x86 style call-gates stuffed on top

Huh, interesting. I don't know a lot about the various architectures, but with instructions like that, my intuition tells me you could do some really interesting stuff.

Coming from an embedded background, I'm wondering, could you not, for example, do a machine where you offload bulk memory operations to the memory controller itself? Copying memory, zeroing memory, moving memory around, all these things could happen at the memory controller level and you'd never need to put them on the actual bus. Perhaps there is something like this for some exotic architectures?

Something like the 1985 Amiga blitter chip?

I've seen obscenely complicated DMA controllers that can do that and more. Check the NXP iMX6 SDMA peripveral for instance.

It would still put it in the bus, tho, no?

I'm wondering now how these processors/MCU's handle bus access since you have so many peripherals that probably want to access it as well as the CPU acceses that need to happen. Certainly you have to have a priority settling mechanism and some way of arbitrating the resource. The CPU probably doesn't use it all the time, but if you have a pipeline, it probably uses it in the background anyway.

On ARM there's a whole series of controller blocks that sit between the CPU caches and the outside world. Start looking up the AMBA (Advanced Microcontroller Bus Architecture) and you'll see how complicated it gets:

https://developer.arm.com/architectures/system-architectures...

Tons of classic CISC have strcpy memcpy, memmove, etc implemented as instructions. S/360 and x86 do too. The reason is that the early incarnations didn't have instruction caches, so you could get a ton of perf on these common operations by executing the move almost entirely of out of ucode, therby keeping the instruction fetches from conflicting with the data accsesses and stealing bus bandwidth. Like 2x-3x increased bandwidth typically.

That's still true with REP MOVS/REP STOS today in x86, it runs in an internal loop (and reads/writes cacheline-sized blocks if it can) while the rest of the CPU can continue executing other instructions in parallel. You can achieve similar results with vector instructions, but those tend to take up a lot of icache and also fetch bandwidth.

Modern CPUs can be efficient target for C, but that's mostly because C standard is full of "undefined behaviour" for a ton of stuff - so that compilers can do weird things to optimize for hardware.

Not like the CRISP! It implemented the C call stack in hardware, with no registers—almost every instruction directly addressed memory, or the register-like arguments on top of the stack.

No, certainly not. The ones that weren't mostly failed, though, yes, although the ones that are aren't optimized in the same way.

Reply on news.ycombinator.com