Stack Computers: 4.4 Architecture of the Novix NC4016 (1989) | Hacker News Reader

Stack Computers: 4.4 Architecture of the Novix NC4016 (1989)

users.ece.cmu.edu

45 pointskristianp21 comments

The Novix was crazy fast when it landed. I had access to one of the first samples and we had to sign all kinds of stuff to get our hands on one. Rumor had it that it was part of what went into the Tomahawk, but I've never been able to substantiate that. I used it for image processing.

The later versions of the same software ran on regular x86 hardware, which caught up pretty quickly with custom processors. I had a DSP032 which also ended up in the drawer because of the speed with which regular processors improved.

Interesting that now, a good 30 years later we are again using co-processors.

I think it was Joel McCormack who wrote a paper (context: X11 display servers) that basically said that in the long run, dumb frame buffers were probably better than dedicated graphics processors. He reasoned the general purpose processor guys were improving performance faster than the dedicated GPU folks were able to due to greater scale and resources. They were therefore able (eventually) to perform the same graphics primitives just as fast as the GPUs, and were using up all of the memory bandwidth anyway.

That doesn't seem to be as true any more, and there were always corner cases (e.g. hardware accelerated mice sprites, I think, were always a win for various reasons), but it was an interesting debate back in the day.

That all changed when high level primitives and floating point operations were moved to the graphics co-processor. SIMD at that level was a game changer. I wrote a graphics driver for the BBC Micro to use the Elektor 'GDP' as an output device, it totally blew the 8 bit CPU of the day out of the water.

These things tend to oscillate, presumably one day there will be another generation of CPUs that is much closer to our current CPU/GPU combo that will outperform GPUs and then the cycle will start over again.

it totally blew the 8 bit CPU of the day out of the water

I think the counterargument in this context would be "...until we all went to 16-bit processors.". But I understand the point you're making.

These things tend to oscillate

I think you're of course correct, and I don't think the original paper disputes that. What I think (without much research) has happened is that the period of that oscillation has dramatically expanded since the paper was written.

I got to build algorithms for Novix's successor, the RTX2xxx family at Harris Semiconductor. Holy cow, it was fun teaching customers how to wrap their heads around a fully stack-based instruction set. :-)

For those missing the context, this was a circa 1985 attempt to execute Forth almost directly in hardware.

Very cool, and a bit weird by 1985 standards

How does this architecture perform in terms of FLOPs per Watt, compared with traditional register based architectures?

It doesn't have a floating point processor so it would not do FLOPS very efficiently compared to modern machines.

In that era the power to performance ratio was not as critical since the clock speed of this device was typically sub 12MHz. (yes that is 12,000,000 Hz) Power losses are quite a bit less than at 1.2GHz

FLOPs is probably not a very sensible measure for measuring hardware from 1985, nothing had FPUs back then.

Novix claimed that it achieved 10 MIPS at 7.5Mhz drawing about 0.35W. Kind of hard to verify how accurate their claims were with the chips being impossible to find though.

Also from 1985, a 20Mhz MC68HC000 drew 0.38W[2] for 3.5 MIPS (going by 0.175 MIPS/Mhz[3]).

So if you believe Novix's claims it had really good power efficiency for the time.

[1] https://en.wikichip.org/w/images/a/a6/nc4016.pdf

[2] https://en.wikipedia.org/wiki/Motorola_68000

[3] https://en.wikipedia.org/wiki/Instructions_per_second

As I remember it they claimed much faster interrupt handling too -- I don't remember the details. Something like only having to save a couple of hardware registers.

Exactly. Task switching was (if memory serves - no pun intended) no more than 3-4 references.

I think the only hardware implementation was on a FPGA. I don't see why the Novix architecture could not be re-implemented using modern chips; e.g. 64-bit, 2GHz, onboard cache, etc.

A gate array iirc, but definitely not FPGA: I remember reading in the manual that there was a bug in one of the instructions (the multiply-step, I think?). With an FPGA they'd surely have just fixed it instead of shipping a batch of buggy chips.

Forth is a bit weird by 1985 (or any year's) standards, so a chip designed to execute it directly will be a bit weird too!

For example, Forth uses separate operand (data/parameter) and return stacks, instead of interleaving them in main memory like most CPUs and runtimes. So the Novix has separate memory and busses to the return stack, operand stack, and main memory, and it can independently push or pop from them in parallel, in the same (bit-sliced) instruction! And that's frequently useful:

>The NC4016 subroutine return bit allows combining a subroutine return with other instructions in a similar manner. This results in most subroutine exit instructions executing "for free" in combination with other instructions. An optimization that is performed by NC4016 compilers is tail-end recursion elimination. Tail-end recursion elimination involves replacing a subroutine call/subroutine exit instruction pair by an unconditional branch to the subroutine that would have been called.

>When the NC4016 was designed, gate array technology did not permit placing the stack memories on-chip. Therefore a minimum NC4016 system consists of three 16-bit memories: one for programs and data, one for the data stack, and one for the return stack.

Stack machines were never very popular outside of Burroughs. Burroughs built several of them implementing a number of elegant ideas.

When Algol first came out, they put a grad student summer intern onto the project of writing an Algol compiler, from scratch, for one of the stack machines. The intern completed the entire compiler in one summer. So, the question is, was the compiler a single summer intern project because stack machines are so well suited to Algol, or was the compiler a single summer intern project because the intern was Don Knuth?

The HP3000 [0] ("classic", pre-PA-RISC) was stack-based. It was a pretty popular business machine; the Classic architecture was produced between early 70s and early 90s. It was 16-bit, segmented, Harvard, and competed against IBM S/32 - S/36, AS400, PDP-11, and Vax. To most programmers there wasn't anything too special about the architecture; almost all development was in RPG, COBOL, or a really incredible (for CRUD) 4GL product from Cognos called Powerhouse [1].

[0] https://en.m.wikipedia.org/wiki/HP_3000

[1] https://en.m.wikipedia.org/wiki/PowerHouse_(programming_lang...

Actually, there were a number of stack machines that were pretty popular in the early days beyond Burroughs (which still exists). As mentioned, the HP3000's were stack machines and hugely popular. The ICL2600 and early Tandem machines were stack machines. And so was the Transputer, which still exists in various descendants.

As to Algol, there's certainly a case that a stack machine is a nice abstraction for targeting an Algol compiler. However, having toyed around with writing an Algol compiler, I think the fact that it's a compact, well thought out language with an rigorously described syntax (BNF) that makes it relatively easy to attack, regardless of target.

James Bowman used similar ideas to create J1 in 200 lines of Verilog.

https://excamera.com/sphinx/fpga-j1.html

Made me dig up this old note from 2010 http://www.ultratechnology.com/chips.htm

I had access to a Novix eval system (like a shoebox with a 5 1/4 floppy in the side) at the time and for a lot of things it was _very_ fast - on a par with a VAX 8600 as I remember.

My memories of FORTH are really good too, especially after writing PostScript (FORTH enough) printer drivers that were downloaded printer programs. They turned further downloaded lists of nodes into properly placed topological diagrams and printed them out.

Reply on news.ycombinator.com