3 ms·
Ya 68k assembly was the simplest assembly language I ever used, far simpler than either x86 or z80. I embedded it in asm {} blocks in C++ back in the Mac LC day
by zackmorris 3y ago
Ya 68k assembly was the simplest assembly language I ever used, far simpler than either x86 or z80. I embedded it in asm {} blocks in C++ back in the Mac LC days for innermost loops, and the great thing was that the compiler would even let you reference variables like "register int x;" declared outside the block, instead of having to keep track of r0-r31 (if I remember correctly). One of the only problems is that it's a very RISC-like instruction set, so is missing much of the high/low byte handling of x86, as well as fancier combined MOV/math/loop instructions with side effects that could be taken advantage of for games. Which in practice meant that the same code ran perhaps 2-4 times slower on Mac than PC.
Unfortunately Apple crippled the memory bus on most of its products so as not to compete with its more expensive models like the Mac IIfx. So by the time the 486 DX4 came out, there was simply nothing comparable on the Mac side, and then the Pentium was the final nail in the coffin and Apple had to transition to PowerPC. But modern processors are so microcode-heavy, with advanced pipelining, branch prediction and instruction interleaving, that they can't be programmed by humans anymore, at least not anywhere near the level of optimizing compilers. GPUs also killed the golden age of innermost loop optimization in the late 1990s.
If I could have one wish, it would be to revert all processor "progress" since the 68040 or possibly PowerPC 601 around 1995, and make something like RISC-V with under 1 million transistors, little or no cache, and 68k assembly or simpler. Then arrange them on a 2D grid. The 50 billion transistors of an Nvidia RTX 4080 would make for 50,000 cores, and even if we lose 1-2 orders of magnitude for interconnect, that's still 500 cores. I'd put at least a 16 GB memory directly above that, connected by vias, with a content-addressable caching scheme for in-memory processing. A scalable chip like that would give us 3 orders of magnitude more performance than we have today, and pull away at perhaps 100x improvement each decade. Maybe Apple's M1 will eventually do that stuff, but right now it's too mired in domain-specific hardware for video and AI. I view that with the same skepticism as DSLs and mourn the loss of symmetric multiprocessing. But I digress!
- convolvatron 3y agoI've worked on .. several? high core count 2d array machines, and they tend not to be to useful for general code because of limited memory bandwidth. some pipelines and embarrassingly parallel things work really well. generally machines with higher dimensional interconnect tend to be more useful I agree we shouldn't have completely abandoned these machines in the 90s. the massive resurgence we see of vector and simd today proves that there was substantial value - and maybe the software story would be a lot better if we hadn't have taken a 20 year piss break.
- cmrdporcupine 3y agoIt's true, I can't help but imagine what we could do if we just down-clocked CPU in at the same maximum speed as the bus&RAM and went stupid-wide instead of stupid-complicated. Forget about smartly filling our L1 caches, super clever branch prediction, NUMA, very wide register sets, etc. and just go "embarassingly parallel" as you say, and with the right programming paradigm perhaps the tradeoffs would work out in either $$ or MIPS. Though of course I know it's been done and either failed technically, or failed in the market, several times. E.g. fairly recently the Parallela Epiphany stuff (https://parallella.org/2016/10/05/epiphany-v-a-1024-core-64-bit-risc-processor/ https://parallella.org/2016/10/05/epiphany-v-a-1024-core-64-...) which sounded super-gee-whiz-bang-neat but went nowhere. But maybe the application domains and compilers just weren't there for it yet. I like what e.g. Parallax has done with their Propeller 2, in the microcontroller domain. 8 cores round-robining on a shared memory, but with their own smaller localized workspace RAM, and a pile of I/O. No need for interrupts to manage concurrency, just assign a core to it. https://www.parallax.com/propeller-2/ https://www.parallax.com/propeller-2/
- dontlaugh 3y agoEmbarrassingly parallel problems are relatively rare. Even GPU cores are quite big and they’re explicitly dedicated to mostly embarrassing parallelism. The complexity is sadly mostly inherent in the problems being solved.
- convolvatron 3y agoone place where more software/language/architecture work is really needed to make this work well is architectures which aren't cache coherent (either by simply not having any caches like the MTA or the CM, by having software controlled caches, by strongly delineating local and global memory, or some other approach).
- cmrdporcupine 3y agoI've been sitting here in my spare time writing / yak shaving an adaptive radix tree implementation I wrote... to try to keep various things in L1 cache and, well, y'know, it'd be nice in a way to just sometimes... have this all be explicit and not automatic? To be able to put the machine into a mode where I could have the various levels of memory declared by the hardware have separate manual methods for accessing each, e.g. to be able to load L1 myself, etc. The CPU & board could tell me the size and cost of each level, and I could write a software model to move things around myself. Fantasy.