Mark Smotherman

One of the best intros to microprogramming: https://people.cs.clemson.edu/~mark/uprog.html

> 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…

"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&CF… 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…

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.

It was the DG Eclipse MV/8000. There's a pretty good overview/references at https://people.cs.clemson.edu/~mark/330/eagle.html. There is little new under the sun, and I get a migraine from the reflexive eye-roll when I read about some 'totally new and original innovation' in computers that's actually been around for decades, usually touted by people who weren't even alive when it was first created.

My understanding was that much of the design of ARM was literally based on 6502: https://en.wikipedia.org/wiki/ARM_architecture#Design_concepts Edit: Granted, Sophie Wilson, one of the designers of ARM, is on record stating that 6502 didn't inspire anything in particular, beside being one of the few inputs to her pool of ideas (16032 and Berkeley RISC being the others): https://people.cs.clemson.edu/~mark/admired_designs.html#wilson So... arguably :)

Which Machines Do Computer Architects Admire? (2001) https://people.cs.clemson.edu/~mark/admired_designs.html

I don't have direct experience, but I believe that system/360 programs have historically not had stacks, opting instead for a statically allocated 'program save area'. https://people.cs.clemson.edu/~mark/subroutines/s360.html XPLINK, a different linkage convention, also for MVS, does have use a stack-based convention: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zo…

Digging into the history briefly, patchable microcode seems to have existed in commercially released computers as far back as the 1960s. "...CCROS [microcode] cards on the [IBM System/360] Model 30 could be replaced in the field. This made design modifications easier to accomplish, as well as providing for field diagnosis. ... The later System/360 Model 25 and models of the later System/370 series were configured with at least one portion of the control store being read-write for loading microcode patches and microdiagnostics." https://people.cs.clemson.edu/~mark/uprog.html

It was originally part of an even more awesome concept called Future Systems, which was supposed to replace the entire IBM universe with capability-based single-level storage systems. http://people.cs.clemson.edu/~mark/fs.html http://www.garlic.com/~lynn/submain.html#futuresys It never got off the ground. System/38 and AS/400 are the only visible remnants of it, survivors from an alien world.

Her WP page got me to this nice page: Which Machines Do Computer Architects Admire? http://people.cs.clemson.edu/~mark/admired_designs.html#wilson

Does anybody know more about FHP (the Fountainhead Project) than what little I can read here: http://people.cs.clemson.edu/~mark/fhp.html

I think this is called dual or multi-path execution if you want to Google for it. http://people.cs.clemson.edu/~mark/eager.html says ...I've seen it alleged that some mainframe processors in the 1960s and 1970s executed down both paths beyond a branch; but, as far as I'm aware, multiple-path execution has never been done by a commercial processor.

> 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!)."

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…

> is there an example of machine code that doesn't make use of a linear contiguous call stack? Early CPUs didn’t have support for a stack, and some early languages such as COBOL and Fortran didn’t need one. They didn’t allow recursive function calls, so return addresses could be stored at fixed addresses, and a return could either be an indirect jump reading from that address or a direct jump whose target address got modified when writing to that fixed address (see https://people.cs.clemson.edu/~mark/subroutines.html for the history of subroutine calls) Both go (https://blog.cloudflare.com/how-stacks-are-handled-in-go) and rust (https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html) initially had split stacks (https://releases.llvm.org/3.0/docs/SegmentedStacks.html, https://gcc.gnu.org/wiki/SplitStacks)