😊😊😊plll😊

Impressive! Industrial design is Apple's secret sauce few understand. When it was first revealed at the West Coast Computer Show, the Apple II wasn't the most impressive piece of hardware among the exhibitors. Yet, Apple's booth was mobbed by the press and attendees. Most computer historians credited its successful launch to its color capabilities, but they dismissed the real reason even though it was right in front of them. Unlike the sea of intimidating, ugly sheetmetal boxes with flashing red LEDs at the show, the Apple II was a beauty to behold. It made it approachable and captured the minds imagination. It's amazing Apple continued to place a very high value on aesthetics well after Jobs tenure as demonstrated by the Cray's purchase. Meanwhile, its competitors continued to churn out the same dull, beige, sheetmetal boxes.

Yes, Apple really led the pack in industrial design, even back then. Their enclosures were the nicest-looking and feeling, and easiest to open of any major manufacturer. Apple spent a lot of money on plastics design, which contributed to its status as the "aspirational brand," even through the turbulent 90s. It was fun to see and demo those products when they were introduced. Everyone wanted a peek. Fun fact: the texture finish was applied to the mold tooling only after the designs were frozen, right before production. Up to that point, all samples and test articles came in smooth, untextured plastics. When we showed preproduction demo samples to customers under NDA, it was usually a unit in those smooth-finish plastics. The texture was applied by etching the mold tool in an acid bath, so it was a one-way, non-reversible process. If a mold tool had to be redesigned because of a product design change, it could impart as much as a six-month delay on the product introduction, because making the tooling had such a long lead time. A change like this would have cost many millions of dollars in tooling changes alone. After I left Apple, they started building finished products using smooth, glossy-finish, untextured plastics. This is now much more common than textured plastics, but at the time was unheard-of. Products finished this way require lots of special protective packaging and handling to ensure that the finish is not marred before the customer receives it. Everyone makes electronics that way now, but Apple was the leader. I'm pretty sure the iPod was the first product Apple sold in smooth plastics.

Thanks for sharing! When I got to that part of the video I figured they must have been using the Cray for case air-flow / thermal simulations or something...

If only they stuck to the minimal screw methodology 😤

Cheers!

I'm literally creating a clone of it in a FPGA now because everyone seems to be doing traditional 8bit computers on youtube. I though I might try something different. I love that thing and I think now its the time for such architecture to give fruits. Specially with all systolic array things that's on GPUs nowadays.

​@@monad_tcpCould transputers be used for a new GPU or NPU design?

SARA University compute center in The Netherlands had a Parsytec transputer-based cluster at one time.

@@johndododoe1411 Certainly, that was one of the proposed use cases when the Transputer was created. They had started with some general purpose cores, but were planning specialised ones, including GPU's.

@@johndododoe1411 No. The idea is similar to modern GPUs with programmable pipelines (especially the compute shaders), but they have access to far more RAM with a far wider bus and are much more closely integrated. Transputer is closer in funtion to a modern DSP anyway.

I get the impression hes a stand up guy. Lots of people have very nice things to say about him.

i thout you made a typo for a second and meant a 'huge martini' company🤓

Came here to say exactly this.

agreed

Not all that amazing really. It comes down to time and money. Software developers and operating system developers simply didn't, and even today don't have the time and resources (cash and technical know-how) to support more than about 3 CPU architectures across 1-3 operating systems. I'm a software developer who owns a company doing LIDAR development and I only support 1 operating system across 2 CPU architectures. Paying the salaries for programmers who are coding for rare CPUs and rare operating systems simply isn't wise or feasible from a business standpoint. When the market settled on the 3 major CPU architectures (ARM, Intel, AMD), and 2 major operating systems (Windows and MacOS) it allowed developers to produce better quality products for these few architectures/operating systems instead of creating a crap-ton of shoddy products for more varied operating systems and architectures. It became a matter of quality over quantity from a software development standpoint. Software testing and validation is also quite expensive so supporting 3 architectures triples the cost over just one. I dropped MacOS development because it made up less than 1% of my sales, yet the cost for MacOS development was 2/3 more (mainly due to Apple's app store 30% fees) than developing the same apps for Windows, where 99% of my revenue originated.

Neither is true. The modern CPUs used in macs have absolutely nothing in common with the 1980-ties designs. Nothing.

@@rosomak8244 It's my understanding that ARM RISC designs originated from Acorn in the UK in 1983 (Acorn RISC Machine) which joined into ARM holdings in 1990 (Apple being a partner.) The A and M chips in Apple devices are children of this architecture.

I really need todo a video on that.

Very good point, I keep meaning to dig into how arm implemented that. Next time I'm in the pub with one of them I'm going to try to find out.

@@RetroBytesUK There were two versions of Jazelle, originally called 1 and 2 but later renamed to DBX (direct bytecode execution) and RCT (runtime compilation target). The latter eventually merged with Thumb and is still available while Jazelle 1 was completely killed off. There wasn't much information about it to start with but ARM has put some effort on making what was there go away. Jazelle 1 could translate the simpler Java bytecodes directly to a corresponding ARM instruction with a little bit of register renaming so a group of 4 (I think) registers cached the top of the stack. For the more complicated Java bytecodes it would jump to a small routine in ARM machine language to interpret. But you replaced the main interpreter loop with hardware

TMS9900 was not stack based . It was a simplistic design that used a 32 byte memory structure to hold all the architectural registers in what would otherwise have been a neat RISC design . If only they had loaded those registers into a CPU buffer, it could have been much faster . 8087 was a stack processor without all the basic CPU functions that were done by the 8086 CISC processor .

Using faster (local sram) memory for the registers and slower memory (external dram) for the stack memory is more tradition, not a technical hardware decision. Modern ARM processors talk about register files (physical local sram blocks with individual addresses). That local sram block which could very well hold a fast stack instead of registers. Architecturally, you need pipeline and flag registers all over the place in modern designs - so you might as well use the "register" as the base abstraction, and physically as a design block. That's why the stack becomes a second order abstraction, even though it's crucial for all compilers with subroutines, and a great model for general computing. The control logic defines what abstraction you're implementing to make sense of a memory block. The ALU can work with either register concepts or stack concepts for input and output, it's all just latches at the end of a wire. C compilers want fast registers(because that's all of the fast memory they could fit into old hardware), so hardware designers implement local sram registers. That's why. If Forth was more popular than the fortran and c languages, we'd have fast memory mapped as stacks.

@@PaulSpades Going way back, some early CPU's had the registers on mechanical drum memory in the days when even DRAM was still wild sci fi. I think the formal technical definition is that registers are in whatever is the fastest memory you can afford to pay for at the time.

Are you perhaps confusing the TMS9900 workspace pointer register with an overall stack architecture?

So its trival to write a compiler if you dont mind if the resultent code performs very baddly, on a modern hardware design. If you have to write a compiler so things get taken from memory to the stack so they are there ready when needed, it gets alot more complex. Thats what the compiler team where trying to get across, sure they could make a compiler, but it would perform baddly as they couldn't get to the point where it would be good at get things on the stack in an optimal way.

@@RetroBytesUK compilers for stack machines are much simpler and initially performed as well as compiled code for register machines. That is why machines such as Burroughs 5000, HP3000, Transputer, iAPX432, RISC I to III and Sparc (a mix of stack and registers) and so many others took that route. Improvements to compiler technology in the 1980s in the form of new register allocation algorithms changed this dynamic making register machines more desirable since they were simpler to pipeline. I wonder if advanced out-of-order implementations with register renaming wouldn't make stack machines interesting again?

@@Bebtelovimab What makes you think CISC code is smaller/denser? The demand for small code hasn't gone away - the ability to fit code into L1 (especially) and L2 is still king. My theory of the problem with stack machines is that they create unnecessary dependency chains, which makes extracting insn-level paralellism, super-scalar, pipelining and OoO harder - all things that are core to the performance of modern processors. It's why the few modern stack implementations are very small microcontrollers focusing on realtime control.

​@@paulie-g Literally textbooks to this day teach CISC instructions as being more dense than RISC. They use Chinese versus English as an example. And this was not that old for a college textbook (2018), so they knew of RISC. Although they mention Itanium's EPIC without mentioning the whole Itanic thing. I had a laugh when reading it before class (not in public). Although they also still cover optical media (i can understand LTO). For reference, this was a basic introductory computer course (in Information Systems, Comp Sci with less low-level programming and more business admin), that dealt with basic concepts.

@@alext3811 OK, so the answer is "someone said so in a textbook", with the textbook being generalist rather than specialist. Gotcha. Density of instruction set =/= density of code. The comparison is not RISC per se but load-store architectures. I bet they hadn't heard of Thumb. There's enough pointers for you to educate yourself if interested.

That's basically it, with stack processors of the time, the stack the processor could access was held entirely on chip. Instructions (expect load/store to and from the stack) could not access conventional ram. They only operated on the stack. This leaves the compiler having to schedule all load/store operations to conventional ram, a more or less impossible task for it todo optimally.

Other none pure stack designs muddy that water a bit. The key advantage of a pure hw stack processor is everything you need is in the stack on the chip, there are no slow calls to/from ram. Which is great for things where all the code that will be ran fits in the on chip stack. Where that's not the case these designs have an issue with scheduling stuff off/on the stack. Some improvements on that type of design (in terms of making it more useful for regular computers) is the stack register, which allows for mutplie stacks to exist on chip with the stack register controlling which stack is in use. As the os schedules different processes (or threads) the stack register is updated so it points to the stack related to the scheduled process. That can be combined with load/store operations for the none active stack, so when the task related to that stack is running its not waiting on load/store operations.

However there is always an issue with how much sram you can fit on die, as the gate count for doing that soon gets very large.

It not about writing a basic complier like the for the JVM. They needed a compiler that would be performant on thier hardware. This is where it get difficult, the compiler has to schedule all the transfers between ram and the stack. The compiler must get the timing of the right so what is needed on the stack is there when it is needed. Doing that for compiling just one application is tricky. Now imagine doing it when it's for a task switching OS, how does the compiler do that in a optimal way.

Compilers targeting stack based VMs can be nice and efficient as they can ignore the bandwidth limits between the stack and ram. As the native CPU does its best to optimise that with cache pre fetch, branch predication. If it's for a HW stack processor everything is the compilers problem.

Do you think the difference in compiler complexity might be between a conceptually infinite stack growing in general RAM with operations which can source from arbitrary offsets on the stack to a system, and a small on-chip stack for which operations (possibly) have fixed offsets that they source from? Then there'd have to be a general program stack to track recursive procedure calls per thread as well as this hot on-chip stack that data gets pushed onto and popped out of from and to external memory.

Burroughs is a more complicated story because it was specifically hardware and software co-designed (something we desperately need in the modern era) for (what was then) high level languages. The system-level language was ALGOL (60 probably) with a really fast one pass compiler because they departed from the standard by requiring definition before use enabling one pass compilation, which was a huge deal in the days of punch cards. Incidentally, none of those HLLs would be implemented with a stack machine today. A good example of a modern attempt at something similar is the Mill, at least conceptually.

@@paulie-g Interesting, thanks. My only direct experience was on an A series using that C compiler I mentioned.

Xilinx FPGAs ( 4000 Series) ? 2 32 Bit Transputers and 2 16 Bit Transputers ?

Indeed. I was also a bit surprised by that statement. Virtual Machines (in the language area, not the whole computer like vmware) are a intermediate step during compilation of a program. It makes it (comparably) easy to write the compiler from the language to the intermediate code. And the second compile phase (just in time) is when the code for the stack machine is translated into architecture specific code. But you are right. Real world applications would run incredible slow with a stack based machine because it would require lots of (slow) memory access. And it would probably also not work well with pipelines (where the processor executes several instructions at the same time by slicing them into microcode operations like fetch, load, execute and store.)

I probably should have been more clear, its hard to write a performant complier for HW based stack designes, as working out when/what to get into the stack is hard, so its there ready in the stack when needed. Making it the compliers problem rather than the cpus (prefetch, branch prediciton etc) hugely increases the complexity for the complier writter. For solutions like the JVM you can basically ingore that stuff as the native cpu will do all the prefetch etc. They where targeting performance, so when the compiler team told them it was too complex to make a perfomant compiler they moved on. Ocam and the transputer cleaverly avoided the big performance issue, by using message passing (which everything was optimised for), where other system used shared memory, this avoided using the technique that was a big source of issues with parallel computing and also the preformace issues of having the complier dealing with planning all transfers from ram to stack.

@@RetroBytesUK In a stack-based machine, all data lives in the stack. It either is at the top-of-stack or just below it, for temporary data used in expression evaluation, or in stack frames below that for local variables of the functions. That is why stack architecture fits compilers for structured language so well: there is a direct mapping between variables in the language and locations in the stack, without the detour via processor registers. This has other advantages as well: context switching becomes much simpler. To switch thread, you just reload the stack pointer and program counter. No need to save other registers because there aren't any. Process context switching of course is more complex as memory management is also involved. But there are performance problems because everything is in memory. However, an optimized processor would have cache to hold the most frequently accessed stack locations, at least the words at the top of the stack and a dynamically assigned cache for the locations beyond that. It is not the task of the compiler writer to manage that. Maybe at Apple they decided that (at that time) making the processor clever enough to manage the cache was too difficult, and that task would be passed on to the compiler. Yes, that would make it complex. But it also is a bad design decision to begin with.

That chimes with what more or less everyone who has spoken about meeting him had to say about Sculley.

In the developer community in the late 1980s there was a common saying... "Lynch the rat-bastard Scully."

He may have been a bastard, but I don't credit the claim that he didn't understand Pepsi. It's sugar water with a colorant and carbon dioxide. What's hard to understand about that?

@@paulie-g The problem was that he didn't care what the business was. Being hired by Jobs (someone who is overly passionate about products and their impact in society) the end result was Skulley just running a computer company like he did a softdrink company. In a PURELY money sense, maybe those differences don't matter, but it does very much matter. Skulley left the company in a state that did not recover (and almost insolvent) until Apple rehired Jobs after the Next acquisition. I don't idolize Jobs and I own no Apple products, but Skulley was always wrong for this company. He did do wonders for Pepsi in his time there, but I just don't see him ever caring about the difference in importance between softdrinks and technology. Jobs famous quip while convincing Skulley to come on board is very popular(Sugar water vs changing the world) was a good pitch, but it doesn't seem like he toook it to heart and helped ruin the company anyway.

@@MicrophonicFool So, long story short, dirtbag Jobs nearly ruined his own company and got himself the boot by foolishly hiring Skully, a bigger douchebag than himself? LOL

Sorry, I will duck that one a bit more in future.

there was also the mac os jaguar that was pretty successful too.

Cracking machine for its time, saddly I only have later Acorn Arm machines, but I do love them.

Same: I saw the ISA and hardware specs, and immediately realised its brilliance, so rushed out immediately and bought an A310, which is still in full working order, including the monitor, and still in very good condition with all the original manuals and packaging, and no, it is absolutely not for sale. I also had the same thought on RBUK doing a Transputer episode, about 15 seconds into this video.

To be fair, the voltages were not tiny, they were the regular operating voltage of the CPU and the CPU was operating from normal voltage minus one Schottky junction. It's uncommon to parasitically power a chip through abusing the I/O protection diodes but I've seen it done a number of times in circuit challenges and the like.

Completely agree, it just goes to show how even the best ideas need the right timing.

...or stolen, like the "iPod", look up that story and weep.

Sooo good!😂

There was an Apple connection to ARM as well, since it was Apple and Acorn together who worked to spin off ARM from Acorn. Apple sold of ARM stock for years after Jobs returned and didn’t start on their own ARM designs until well after they had divested their shares in ARM.

The Cell chip in the PS3 had some serious design-level mistakes culminating in serious performance issues. There is certainly a way to make multi-core work fast by reducing synchronisation overhead, eg by loosening the coherence guarantees like Alpha did.

@@paulie-g right but the alpha and other multi-processor designs were going for performance beyond what could be practically achieved with a single core/chip using the mfg capabilities of the time and had costs to go along with that capability. There was still a lot of room to just make a faster single core chip at the consumer end of the market, and even if it was theoretically slower than a fully-utilized multi core design it still would have been much easier to program for and so most software would have run better.

It would seem that the 68040 design just couldn't be run at frequencies beyond a certain point, unlike the 80486 which went into its DX2 and even DX4 phases. So, even though the 68040 kept Motorola competitive with the 80486 initially, it just wasn't able to keep up. Eventually, the 68060 did come along and seems to have been more scalable in terms of frequency, but that was only useful to those few platforms that had stuck with the 68000 family like the Amiga (although there were other accelerators for that, too).

Thank goodness someone spotted it, last time I made a red drawf reference, most missed it and told me I'd got what ascii stood for wrong.

I came here to see whether anyone else had spotted it and two people already had! I remember the ASC-II thing too :)@@RetroBytesUK

Shame almost everything released for it only used the 68000 it had.

That RISC core was copied for it’s GPU, too. Problem is it was a new bespoke RISC architecture, rushed out with hardware bugs and immature dev tools. Makes sense to write code for the processor you already understand, rather than the one you don’t and was a nightmare to debug.

@@Toothily I think the difficulty for Atari was they put every last dollar they had into the jag and it was still not enough. So they had no money left todo dev support properly, hence the lack of dev tools which ultimately under minded the whole effort. Its a huge contrast to the effort Sony put into supporting devs for the PlayStation.

@@RetroBytesUK Yeah it was do or die, but I respect what the engineers were trying to do. It’s still a clever design, even if it only got to ~80% of were it needed to be.

@@Toothily It was a small platform with a small install base. Devs didn't want to write exclusive games for it, so they either wrote games they could port to other platforms or ported existing games, all of which dictated the exclusive use of the 68k.

🤣

They really did seam to think for quiet a while this would be the new cpu for the mac at the highest level of the company. As far as I can tell they where still a way out from doing any layout work, so as you said it may have been far too expensive to be practical in the time frame they where planning on. Its the problem with a secret project, there are not many source to go off, so you never can be sure.q

I'll look into that, my editing software has gained better support for YTs lufs level, so I should get a better view on loudness.

​@@RetroBytesUK For me it is your voice being to low compared to the music that is the problem. I need to concentrate very hard to get everything. I can live with the overall volume being low since my listening device has a volume control.

@@RetroBytesUK the video in general is too quiet, I have to artificially pump up loudness above 100% on my phone for it to be hearable with any sort of background noise (open window etc.)

@@balukrol Same: I needed +3 db to follow the narrative, but apart from that it is an excellent video.

Did you buy a CPU unit at 10am in the morning?

I just love the idea of we must keep the project a secret, then one the first things they do is buy the least subtle computer know to man, and whats more they paint it purple.

That was the key to Apples problem to make a compiler that produced code that would run in a performant way is difficult. How does the compiler know when a good time to move data from ram to stack and back. Espically when using a task switching OS. Thats the hard part requiring a degree of presience no compiler can have hence the switch to risc. A vm stack processor is an easier prospect as the native code generated from the pcode runs on a cpu with cache pre-fetch, branch predicition etc. Thats why stack is a popular design for virtual machines, the compiler is relatively simple (as you pointed out) and you dont have to worry about managing when things move from ram to stack.

​​@@RetroBytesUK I've seen you use the RAM / stack distinction several times when answering comments which say some version of _compilers for stack machines are easy_. I think all our default assumptions are that the stack in a stack machine is just a region of ram with the processor holding a single stack top address on-chip in its architectural state. Are you implying that this particular architecture used a fixed-size small on-chip SRAM buffer to hold the stack? A SRAM stack accessible only via push-from-RAM and pop-to-RAM instructions, with ALU operations sourcing the top one or two stack entries and writing to top of stack implicitly? Perhaps something too small to hold the full state of each thread's function call stack, so now the compiler's problem is shuffling data between the conceptually infinite stack in general RAM, which is the easy one to code gen for, and the fast on-chip stack which imposes tricky constraints on code gen?

Yep. Even some of the WDC 65C02 was designed in deference to Apple. One or more instructions were made slightly less efficient and retained certain MOS 6502 quirks to remain compatible with the Disk II controller firmware.

It did mean that, sadly quiet a while back now they changed it to mean Advanced Risc Machine. I guess they wanted to get away from their Acorn roots back then.

It was indeed an XMP, and yes incredibly an iPhone 11 would be able to out perform it all almost all regards. Apart from being a space heater, as a heater the XMP still out performs it.

You got your Iphone numbers way off. That is capable of hundreds of giga flops, depending on what benchmark you are looking at, but even a $5 raspberry pi zero from five years ago can do several giga flops.