Hacker News Reader

Comment by jacquesm | Hacker News Reader

I think part of the reason why generalized CPUs will win over specialized ones every time is that hardware that does one thing well is invariably worse at others and we're in a 'polyglot' environment these days. So if you specialize a CPU for language 'X' it will almost automatically be worse at all the others.

So the mass market will almost always favor general purpose CPUs and there may be niches where you'll find more exotic engines suited for a particular kind of computation, maybe even high level languages in hardware (greenarrays Forth offerings for instance).

View on HN

Sadly can't remember where, but I once read an argument that today's CPUs are 'C Machines'. i.e. C code branches a lot, so we have branch predictors. C code uses contiguous memory, so we have caches. I have no idea if it's a legit argument, but I thought it was interesting.

Yes, of course the modern CPUs are designed with C in mind, and C-based benchmarks are always the first to be used to assess any new architectural change. So calling them 'C machines' is legitimate.

The worst bit of being a 'C machine' is the fact that the integers of unspecified nature and pointers are interchangeable, instead of forcing them to occupy the different register files. Another similar consequence is the lack of type tags, which could have been useful for many high level language features - GC, smarter caches pre-fetching the pointers from structures (most importantly for Lisp - pre-fetching the cons cells, depending on a way they've been accessed).

The key detail is economics, especially back in those days when gates were dear. One of the big things that LMI's Lambda improved on over the CADR was adding a TRW 16 bit multiply chip....

As these designs moved onto custom silicon, gates were at an extreme premium, and things like supporting the tagged architecture consumed resources that a general purpose chip could use profitably.

Now I don't think that matter much at all, if your CPU is a bit bigger you sacrifice a small fraction of caching. The lowRISC project suggests NRE costs are way down (collaboration helps a lot, as well as FPGAs for prototyping) and getting significant quantities of chips on competitive processes is not insane (don't know about mask fabrication costs, but they're evidently not a showstopper).

Oh, and lowRISC is looking to do two bits of tags per word, primarily for safety kludges for current not so safe languages.

The Novix FORTH chip was a pretty cool implementation of FORTH in hardware -- it had separate data and return stacks, which it could push or pop at the same time, so the compiler could combine several FORTH words into one opcode.

http://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.htm...

The Novix NC4016, formerly called the NC4000, is a 16-bit stack based microprocessor designed to execute primitives of the Forth programming language. It was the first single-chip Forth computer to be built, and originated many of the features found on subsequent designs. Intended applications are real time control and high speed execution of the Forth language for general purpose programming.

The NC4016 uses dedicated off-chip stack memories for the Data Stack and the Return Stack. Since three separate groups of pins connect the two stacks and the RAM data bus to the NC4016, it can execute most instructions in a single clock cycle.

http://www.forth.com/archive/jfar/vol3/no2/article38.pdf

The NC4000P is a single chip FORTH Engine based upon minimum hardware concepts developed by Mr. Charles H. Moore. This highly parallel machine architecture directly executes FORTH primitives in a single clock cycle. The initial implementation of this device is based upon a 4000 gate CMOS semicustom integrated circuit operating at an 8 MHz clock rate.

But there isn't such a thing as a "general CPU", is there? Some are more general than others, but just like VM's, CPU's are designed and optimized for a specific flow. You're expected to adapt your problem to the architecture - tagged memory and different underlying architecture could make FP considerably faster (in an ideal world, not saying it'd be easy at all), but instead we have to find ways of shoehorning one paradigm on top of another.

Mass market has already swallowed willingly some highly specialised stuff, like GPUs, for example.

The key to GPUs is sufficient volume to make their specialized designs worth the NRE costs; I don't know of another example like them.

On the other side of the spectrum there is also a whole bunch of heavily specialised architectures on a mass market - microcontrollers, DSP (think Hexagon and alike).

OTOH, GPUs are interesting in a sense that they're not confined in any backward compatibility considerations, and therefore this is an area where most of the architectural innovation is going to happen.

Great, DSPs are a very good additional example.

Microcontrollers aren't, as I'm defining this, because of their simplicity and small die sizes targeted at huge natural volumes.

Mid-range microcontrollers is actually where the Forth chips thrive, so I would not be so sure.

Heh, here I'm going to cheat and say "Forth is sufficiently magic that its success here is the exception that proves the rule!"

I'm very impressed by it. Not my cup of tea, Lisp is, then again they have more than a little bit in common (or so I thought when someone explained Forth to me in the mid-80s).

- Sound cards

- Games consoles

- Computer designs like the Amiga

I've been avoiding mentioning ASICs since I've been defining the category I'm talking about as excluding them. Chips for sound cards definitely fit in the ASIC category as I count it, and have plenty of company. E.g. chips for DVD and now Blu-Ray players. The first generation of OPPO player I bought included an FPGA running licensed Anchor Bay IP, the volumes they anticipated selling didn't justify an ASIC.

Game consoles are a pretty good example, although how often do they adopt truly novel stuff vs. taking off the shelf CPU and GPU IP and making their own customized and cost reducible versions?

The PS-3's Cell is an interesting case, the effort certainly had ambitions beyond game consoles.

I'd argue it and the Amiga (the first PC I thought worth buying) are examples that prove this posited rule of general purpose beating specialized, both were in the end failures.

> I'd argue it and the Amiga (the first PC I thought worth buying) are examples that prove this posited rule of general purpose beating specialized, both were in the end failures.

Doom is often cited as one of the big factors in the downfall of the Amiga, and Doom was only possible because the PC world had embraced GPUs (as well as sound cards).

The Amiga did suffer to some extent from the tight integration, and the lack of easy expandability of the low end models, but the custom chips were vital for the success it did have early on - it would never have achieved success if they'd not been able to offload the CPU to the extent they did.

In addition to this, the Amiga also suffered with the transition to 3D games because of the bet on planar graphics. But this again was one of the things that made it possible for the Amiga to be as impressive as it was in earlier years.

That wouldn't have been a problem except that Commodore failed to realise early enough that 3D was coming, and that they badly needed a chunky graphics mode to stay competitive (and we got quick hacks like Akiko as stopgap measures - a custom chip in the CD32 console that in addition to the CD controller contained functionality to speed up chunky -> planar conversions to allow games to work on chunky modes internally)

Modern PC systems have a massive amount of specialized components, going far beyond what the Amiga ever did - if anything, the architecture of the modern PC validates a lot of the design choices made for the Amiga, by offloading far more work from the CPU (and indeed, adding far more CPUs - things like hard drives now often contain CPU cores a magnitude or more faster than the CPUs on the Amigas)

Valid arguments, and after buying the first model I didn't follow the Amiga story after it was clear it was going to fail.

Doom requiring GPUs would seem to be adding to the argument that for a very long time period as these things go, their specialization paid off given the volume in which they sell. If/when GPUs get almost entirely subsumed into CPUs (I don't have any 3D requirements, and I'm typing this on my first, 1 year old computer with integrated into the CPU graphics), I don't think it'll invalidate their "success by specialization".

However, I think I'll still go with my thesis on the Amiga: the failure to gain sufficient market share and therefore volume, plus poor to bad management, doomed it just like the Lisp Machines. And perhaps the NRE costs on the chipset, perhaps the experience of doing it and facing having to do it again, deterred the managers from going for 3D.

As for modern PCs ... I'm not sure I really buy it. Look at all the discrete TTL in the original PC motherboard: http://mit-a.com/disp/mb1.shtml Look at all the TTL in standard cards for it: http://www.minuszerodegrees.net/5150_5160/cards/5150_5160_ca... And a 2nd generation 3com Ethernet card: http://sishardware.com/unt/20622-3com_etherlink_ii_tp_6330__... All computers, especially all designed for volume production, looked like that, and were filled with cards like that.

I submit that the steady accumulation of all that logic into fewer and fewer ASICs, and much eventually into the CPU (nowadays memory controller and PCIe lanes) and a single chip "chipset", is just natural cost reduction aligned with (massive) volume sales. How to square that with the Amiga's chipset, I'd need to think about. Perhaps later.

> However, I think I'll still go with my thesis on the Amiga: the failure to gain sufficient market share and therefore volume

This depended on where on the globe you are.

In Europe the Amiga was everywhere. I was the only guy in my circle of friends having a PC instead.

What are you talking about? Doom never used any GPU since there weren't any in the PCs. It was banging bytes to the frame buffer. Doom could be faster on PC because one byte was one pixel. On Amiga, one had to use bitplanes which killed performance unless one could use the Blitter.

He might be thinking about the Doom version that had later Glide and MiniGL support.

Reply on news.ycombinator.com