Mark Smotherman

"I know a number of people who were on the team that tried to "implement" that architecture, and it's highly unfair to them to call it "bad implementation"."

"The point is, it doesn't matter just how forward looking or elegant or innovative the 432 was, if it wasn't possible to build it."

Let me be clear that I'm talking about the design decisions plus implementation. Subsequent work showed that changes to the design would've greatly boosted performance while keeping the overall scheme of things. Summary in the first link with details in other two.

http://people.cs.clemson.edu/~mark/432.html

https://dl.acm.org/citation.cfm?id=17367&dl=ACM&coll=DL&CFID=742008315&CFTOKEN=45262120

https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf

What are your thoughts on Colwell et al's analysis and suggestions for improving i432?

"There was a reason that the successor i960 was much simpler, and why Glen Myers was brought in from IBM to bring some adult supervision to that architect's sandbox."

I agree with you there. Colwell says i432 was a nice experiment with significant contributions that were forgotten as it failed. I can see that except that it was intended to be a product. Myers understood that products and experiments were two, different things. Hence, the better results with i960. Very unfortunate that it was done in by politics like i860, etc.

Matter of fact, I saw a writer recently mocking F-35 because it uses obsolete, legacy i960MX's without realizing…

> OS/400 -- now called IBM i -- sounds like it was ahead of its time:

That's because it's the last remnant of Atlantis.

https://people.cs.clemson.edu/~mark/fs.html

> The IBM Future System (FS) project was a design effort to succeed the IBM S/370 architecture that was adopted company wide in 1971. FS was based on a single-level store with automatic data management. The project is reputed to have cost more than $1B when it was cancelled in February 1975, but the single-level store idea was adopted by System/38, AS/400, and iSeries.

Single-level store is IBM's cutesy way of saying that there's no application-level distinction between disk and RAM: It's all data, applications access data (or don't, depending on a security model), and the OS handles persistence the same way it handles caching; that is, transparently.

Anyway, security was important to IBM, particularly the security to be free from people making clones of FS hardware. This had unfortunate effects on the systems's comprehensibility:

http://www.cap-lore.com/CapTheory/KK/FS.html

> Some suggest that this memo[0] was the beginning of the end of IBM’s Future System. The section of the memo with “security” in the heading, concerns keeping the architecture secret, from most of those working on the project. Quote:

>> Tight security prevents a potential thief from stealing a system design. But good communication is necessary to design a system that is worth stealing. The recent version of the RIPON architecture has…

Why are x86/64 processors used for most high performance applications then?

Well, you should start from this and then work backwards because it's just an empirical fact that x86_64 is fast and that RISC isn't. There are many reasons for that, none of them fair, but in the end, it's still just a fact.

Yes, RISC-V is simple+elegant. If that's what you want, great. True, RISC-V is open source. If that's what you need, awesome. Now weigh those qualitative features against the cold hard $1B/year that Intel invests in making the mess that is x86 run fast. Add to that the billions that ARM+Samsung+NVidia+Apple+... spend on making ARM fast. It's not a fair fight. It really isn't.

But know this. If RISC had anything tangible, any fundamental advantage, then we'd be living in a RISC world by now and we aren't (Patterson+Ditzel was 37 years ago). If you want to think worse is better, sure. Whatever. If you want to call ARMv8 MIPS-ish, that's your constitutional right.

Skylake is a superscalar, speculative, out-of-order, renaming, hyperthreaded multicore beast. You may program it in x86 but those instructions get translated+cached as μops, very wide microinstructions.

BTW, anyone who thinks that μops are actually RISC under the hood severely needs to re-read The Case for the Reduced Instruction Set Computer and then say, Inside Nehalem [1] or Micro-operation cache: A power aware frontend for variable instruction length ISA [2]; microprogramming (vertical+horizontal) predates RISC…

never did trust a processor or IDE component, from the day i learned how to use them.

Whitepapers made me suspicious, the reserved words or bit values that where mentioned but not documented despite the parent function being extensively documented was one of the reasons.

the results of bit walking hardware instruction sets and trapping the resulting output states gave me cause to suspect things.

the long and short of it is digital hardware is not open source, and is not an operationaly secure platform.

The advent of microcode, was a major turning point, as processors were effectively wiretapped at that point.
It was heralded as a way of fixing mistakes, post-production, so you could reprogram the microcode to do things differently. This puts the user in a very compromised situation, and is getting to be quite extensive as industry has gone beyond simple browser manipulations, and is actually reaching into the firmware that drives the hardware components, and manipulating systems out of band with the processor. The result is a compromised network of digital processors hosted on your mother board.

So what can we do when we design hardware? How about trap and dump?
if a word shows up on a bus, a home rolled bus controller/hard wired analogue device could quench that word, [trap-dump] so any and all compromised digital components would not hear evil instructions, and would be muffled from issuing evil bus words.

The microcode is something that is usually an encrypted…

> Today we might be running a 64-bit derivative of the 6502!

The designers of ARM used 6502 before and one of designers admits there was some inspiration from that:

https://people.cs.clemson.edu/~mark/admired_designs.html#wilson

"I learned about pipelines from it (by comparison with the 6800) and its designers were clear believers in the KISS principle. Plus the syntax of its assembler and general accessibility of it from the machine code perspective. I can still write in hex for it - things like A9 (LDA #) are tattoed on the inside of my skull. The assembly language syntax (but obviously not the mnemonics or the way you write code) and general feel of things are inspirations for ARM's assembly language and also for FirePath's. I'd hesitate to say that the actual design of the 6502 inspired anything in particular - both ARM and FirePath come from that mysterious ideas pool which we can't really define (its hard to believe that ARM was designed just from using the 6502, 16032 and reading the original Berkeley RISC I paper - ARM seems to have not much in common with any of them!)."

I've appreciated your comments elsewhere, but I'm really dubious that a book that only covers the Pentium II as an addendum can offer any specific advice that is still useful. You're sure? I'm intrigued enough to try to get a copy from the library.

I did just read a great explanation of how the P6 generation the Pentium II belongs to differed from the previous one in that it was the first Intel to have Out of Order execution: http://people.cs.clemson.edu/~mark/330/colwell/p6des.pdf

I'd love to find a more up to date book on such topics. Currently I'm struggling to understand how speculative execution works (or doesn't work) in cases that are bound by the front end's constraint of issuing only 4 instructions per cycle. Do you give up all preloading when you are front end bound? It would seem like the PC and speculative PC would be running together, and you'd always bear the full brunt of latency.