[HN Gopher] IBM PC 8088 replaced with a Motorola 68000
___________________________________________________________________
IBM PC 8088 replaced with a Motorola 68000
Author : elvis70
Score : 116 points
Date : 2023-05-12 13:25 UTC (9 hours ago)
(HTM) web link (microcorelabs.wordpress.com)
(TXT) w3m dump (microcorelabs.wordpress.com)
| zwieback wrote:
| I vividly remember how sad I was when IBM chose the 8088, should
| have been 68K.
| randombits0 wrote:
| I like this guy. He does strange things with hardware. Z80 on a
| Teensy 4? No problem!
| klelatti wrote:
| IBM, of course, did use (re-microcoded) 68000's in a PC product -
| the XT/370. With a modified 8087 on a couple of cards these were
| used to emulate an S/370.
|
| https://en.wikipedia.org/wiki/PC-based_IBM_mainframe-compati...
| rjsw wrote:
| IBM also made a standalone 68000 computer, the System 9000 [1].
|
| [1] https://en.wikipedia.org/wiki/IBM_System_9000
| sombragris wrote:
| Correct.
|
| A detailed description (with pictures) can be seen on page
| 278 and following ones of BYTE Magazine, February 1984 issue.
| The computer was branded as "IBM Instruments"
|
| https://archive.org/details/byte-
| magazine-1984-02/mode/2up?v...
| stefric wrote:
| Don't you love geeks...
|
| This was a simple and fun read while waiting for my coffee to be
| done. I also wonder how the world would look if IBM partnered
| with Apple rather than Microsoft.
| glonq wrote:
| > I also wonder how the world would look if IBM partnered with
| Apple rather than Microsoft.
|
| Possibly underwhelming, if Taligent was any indication.
|
| https://en.wikipedia.org/wiki/Taligent
| ch_123 wrote:
| IBM also had experience of the 8085 and 8086 from their System/23
| and Displaywriter systems which meant there was previous
| experience with Intel microprocessors in IBM at that time. I also
| read somewhere (but do not have a source to hand) that IBM had a
| significant investment in Intel at that point in time.
| Dwedit wrote:
| If you wanted to run 68000 code as fast as possible, nowadays
| you'd use a recompiler emulator.
| skissane wrote:
| > It could also have been the case that Microsoft did not have an
| operating system or BASIC ported to the Motorola 68000
| architecture.
|
| The late 70s / early 80s incarnation of Microsoft was happy to
| port their software to just about anything, so long as there was
| a customer willing to pay for it. If IBM had asked Microsoft for
| a 68K OS instead of an x86 one, Bill Gates would have found a way
| to provide. He bought PC/MS-DOS from another company, he probably
| could have found someone selling a 68K OS instead. Or Tim
| Paterson surely could have ported it to 68K if asked.
|
| I think choosing the 8088 over 68K was all about hardware costs,
| not software-both the cost of the CPU, and the cost of compatible
| peripheral chips.
| aidenn0 wrote:
| I don't have a source handy, but I remember reading it was
| because the 68k was too late to production; it was scheduled to
| be ready on time, but the Intel parts were already available,
| and IBM didn't want the risk
| freitzkriesler2 wrote:
| An alternate timeline where 68k was the dominant OS
| architecture? Man what a fun thought experiment. Reminds me
| of Palm OS and their OS5 68k emulator on top of arm.
| snvzz wrote:
| OS architecture? Not ISA architecture?
| skissane wrote:
| My own thought experiment - what if "old IBM" had
| intervened in the product and tried to make it more "IBM".
| Well, if they'd done that too much - e.g. a corporate edict
| that it had to use EBCDIC instead of ASCII - that probably
| would have killed it commercially. But what if "old IBM"
| had just demanded ASCII-EBCDIC conversion in the BIOS? With
| a "code page" field in each directory entry, which could be
| used to mark files as ASCII or EBCDIC (0=binary), with the
| BIOS ASCII-EBCDIC conversion service invoked to make EBCDIC
| files appear as ASCII to applications? That might have made
| the product more "interesting", without adding so much
| complexity as would kill it. z/OS Unix has code page
| tagging in the filesystem; apparently IBM tried to get it
| added to DOS during DOS 4 development, but it got pulled
| before release (although that was not for EBCDIC, just for
| tagging which ASCII code page a file was)
|
| Maybe even demand some optional record-oriented support in
| the filesystem (e.g RECFM=F80). That would have been less
| alien to Microsoft than you'd think, because Microsoft
| BASIC always supported record-based file access.
| zabzonk wrote:
| > and the cost of compatible peripheral chips.
|
| particularly this, i think, and also availability.
| exsf0859 wrote:
| Cool hack! Also interesting that the performance is no better,
| presumably due to the lack of cache.
|
| The first answer on this forum post has what is probably the
| correct explanation for why the 8088 was chosen:
|
| It was available, had a second source, and was not owned by a
| competitor.
|
| https://retrocomputing.stackexchange.com/questions/16912/did...
|
| Although ease-of-translation from 8080-based CP/M code was a
| benefit of choosing the 8086, this was just a nice-to-have, not a
| deciding factor.
| ok123456 wrote:
| All the bus/memory timings are the same with this guy's hack.
| So it's not a big surprise that 10 print "hello world!" :print
| "!" : goto 10 doesn't have any perceived performance
| difference. Maybe if you made a purely arithmetic benchmark in
| assembly that could be done all within a few registers, like
| Fibonacci, you might see some difference.
| guenthert wrote:
| > Also interesting that the performance is no better,
| presumably due to the lack of cache.
|
| Here an (emulated) MC68000 is pressed into serving an 8bit bus.
|
| The 68k (using its native 16bit bus) is faster (even if not by
| much) than a 8086.
| phkahler wrote:
| Not sure about the authors performance claims. He doesn't
| indicate how fast his emulated 68000 is in terms of MIPS or
| equivalent MHz. It's also constrained by the 8bit bus which might
| have been wider if IBM had chosen that chip. Certainly would have
| been wider by the 286 equivalent generation.
| actionfromafar wrote:
| And the 68k has better instructions. Many calculations would
| have been faster.
| cmrdporcupine wrote:
| Author should port EmuTOS to it. Or at least just EmuCON, the
| console-only variant (basically GEMDOS)
|
| https://emutos.sourceforge.io/
| klodolph wrote:
| According to history, there were three microprocessors in the
| running for the IBM PC. They were the Intel 8088, the Motorola
| 68000, and the Texas Instruments TMS99000.
|
| If I remember correctly, the Intel had lots of 8088s available
| immediately (so IBM could do things like lifecycle testing), and
| Motorola did not have enough 68000s available yet. IBM was
| concerned about how much memory you would be able to use with
| future iterations of the 99000.
|
| The 68000 series did see use in the Macintosh, Amiga, Sharp
| X68000, and it completely dominated the Unix workstation space in
| the late 1980s. There were a lot of companies who thought, "I'll
| buy a Unix license, buy some M68000s, and sell workstations."
| Most of these companies disappeared. Later Unix workstations used
| all sorts of architectures.
| SeenNotHeard wrote:
| As long as we're playing "what if," it's worth reflecting on
| all the hair-raising hacks and tricks Microsoft had to play to
| deal with the x86's quirks as they built Windows. XMS/EMS and
| DPMI were also incredibly painful engineering feats.
|
| While the M68K had its own growing pains (as seen with the
| evolution of the Macintosh), none of them seemed nearly as
| onerous as what was done to squeeze a few more years out of MS-
| DOS compatibility.
| StillBored wrote:
| ? The early mac memory manager in macOS was idiosyncratic to
| put it lightly. By the time multifinder was integrated into
| macos, one might say that it was far worse than anything MS
| was dealing with. I mean at that point they were performing
| many of the functions we depend on MMU's for these days in
| software.
|
| I guess in a way the complexity of the PC has more to do with
| the wide range of platforms, software stacks, etc that were
| being supported more than the architecture itself.
| StillBored wrote:
| Realistically in ~1980 or so the "weaknesses" of the x86
| weren't so apparent. It was 1/2 way between the 8-biters (6502,
| 6800, etc) and the newer unproven designs. Back then even the
| expensive apple /// was limited to 128K of ram and bank
| switching was common so having the x86 segment+offset was a big
| improvement. And of course the 8086 was a more mature design,
| etc.
|
| And frankly despite people wanting to rewrite history there was
| never a time when the 68000 was clearly a better processor. Yes
| years like 1985 when the amiga was released machines it showed
| up in looked light years ahead, but software
| compatibility/optimization/etc meant that within a year or so
| the PC was either on top or close to it again. It wasn't really
| until the early RISC machines started showing up that the PC
| was solidly eclipsed for more than a couple years straight.
|
| And many of the technical things people complained about
| (segmentation, few registers) either were partially false by
| the time they were complaining about them (ex the 386 provided
| flat 32-bit addressing in 1985, and even windows/386 was only a
| year and a half later) or net really a consideration. Ex:
| pascal/c compilers hid register pressure and caches sped up
| stack spilling/etc.
| brian_cunnie wrote:
| Don't forget that Intel had an incumbent advantage: the IBM
| Displaywriter used the 8086 processor [0]. IBM was already
| familiar with integrating Intel microprocessors into their
| equipment.
|
| [0] https://en.wikipedia.org/wiki/IBM_Displaywriter_System
| pbj1968 wrote:
| Also saw use in soda machines... SEGA genesis...
| guenthert wrote:
| In the mid to late eighties, the MC68K was also often used in
| high end (small series) test&measurement equipment, e.g.
| HP3458A and Datron 1271/1281 DMM, HP166x{A,B,C} logic
| analyzers ...
| sprash wrote:
| And Palm devices.
| krylon wrote:
| IIRC, it was also frequently used for arcade games, and office
| printers, too.
| rvense wrote:
| The 68000 is one of the most successful embedded CPUs of all
| time and you could buy the CMOS varients, 68HC000 and
| 68SEC000, brand new from NXP until maybe two years ago ago,
| and derivatives of it (the Coldfire series) are still
| available - though most or all of them are "not recommended
| for new designs" now. I think at least some 68ks are still
| being made by Rochester Electronics, a company that
| specializes in keeping old chips in production.
|
| I have seen 68000's and 68020's in everything from musical
| instruments to electronic measurement equipment to office
| equipment and networking hardware made into the late 90's at
| least. The Coldfire series has probably been all but killed
| off by small ARM chips for complete new product families now,
| but I'm almost certain you'd be able to find several of them
| if you went to your local appliance/electronics store today
| and started taking stuff apart.
| cesaref wrote:
| Right, the 68k was the most logical step up from the early 8
| bit processors in typical home computers (except for the
| TI99/4a which went in another direction). They were easy to
| design for, and easy to program (68k assembler is pretty
| elegant). The 68008 as mentioned was used in the Sinclair XL,
| with the 32 bit bus versions in the ST/Amiga/Mac. Initially
| limited to a 24 bit address bus, but when a machine was topping
| out at 1Mb, 16Mb seemed a long way away!
|
| I think the MMU was introduced with the 68020, which then
| appeared in early Sun 3s, and HP9000s, prior to the RISC
| invasion. Those machines seemed super fast at the time.
| pinewurst wrote:
| Motorola sold an MMU that was paired with the 68020 - the
| 68851, but the likes of Sun kept using their own (which were
| simple to implement, a few fast SRAMs and a little TTL). The
| 68010 was the earliest family member that supported clean
| instruction restart on a page fault and had its own,
| infrequently used MMU - the 68451. Again most system vendors
| preferred to do their own. If you wanted "real" virtual
| memory on a 68000, you had to do kludges like running 2 68ks
| in parallel, switching on every page fault.
| ghaff wrote:
| Motorola seemed to like their separate MMU chips. I don't
| remember the exact models but some of their (largely
| unsuccessful RISC) 88K processors had one too.
| pinewurst wrote:
| You didn't have an option with at least the initial 88k.
| They couldn't fit it all into one chip so you had to buy
| one 88100 and at least one 88200. The next gen 88110 was
| single chip.
| jagrsw wrote:
| > I think the MMU was introduced with the 68020
|
| Apparently it was possible to use MMU even with 68000. A few
| months back someone on HN was describing on how they
| implemented it, even if 68000 wasn't designed for it (?) -
|
| From: https://news.ycombinator.com/item?id=34762508
| "The Sun-1 workstation used a Motorola 68000 CPU at 10MHz.
| This was paired with an in-house designed MMU. It had 256K
| zero wait state memory with parity, and 32K EPROM memory."
| pinewurst wrote:
| The Sun-1 MMU was a base/bounds swapping MMU, not a VM
| paging MMU. The Sun-2 and Sun-3 had the full monty VM MMUs.
| cjsplat wrote:
| Nope.
|
| The Sun-1 MMU was segment and page registers indexed
| hierarchically off the physical addresses.
|
| It was a full page based system with segment and page
| level sharing and protection.
|
| The 68000 didn't support restart from page faults, so the
| runtime model was indeed segment level swapping. (Note -
| not what Linux decided to call swapping)
| ghaff wrote:
| I'd add that I never programmed for the 68K but the 8088/8086
| segment register model was a real pain for low-level
| programming.
| (https://en.wikipedia.org/wiki/X86_memory_segmentation) They
| were also little endian which is arguably less intuitive when
| you're twiddling bytes at a low level.
| mordechai9000 wrote:
| They figured out how to use 16 bits of register space to
| represent a 12 bit memory address. I understand there were
| reasons for doing it this way, but it was painful.
| ghaff wrote:
| 20 bit but yes :-) It was doubtless a clever hack given
| the constraints they were operating under but still a
| pain for real mode assembly programming, especially if it
| was memory constrained. At one point I needed to separate
| out code from in-memory data store for a DOS file manager
| to support larger directory sizes and the segment
| register switching got really ugly.
| mordechai9000 wrote:
| Yes! Thank you, it used two 16 bit registers to represent
| a 20 bit address
| cmrdporcupine wrote:
| As an Atari ST user, I was a big fan of the 68k back in the
| 80s but even I'd have to admit that the 808x architecture
| made the most sense for IBM to take given that it offered
| continuity with the CP/M S100-bus 8080/z80 machines that were
| fairly dominant in the nascent "business computing" market at
| that point.
|
| Forking CP/M (cuz let's admit that's basically what PC-DOS
| was) and offering something similar-but-different to those
| systems was low-risk. And their original intent in fact was
| to in fact sell a full-on CP/M machine.
|
| FWIW the Atari ST is what you get when you take a CP/M/PC-
| DOS-style OS and bolt it onto the 68k. Syscalls were
| basically 1:1 with MS-DOS, and even used an MS-DOS compatible
| filesystem. But big-endian. If you want to see what an IBM PC
| built around the 68k would have looked like, that's not far
| off.
| tom_ wrote:
| The 68000 has a 16 bit data bus.
|
| (I always assumed it's 16 bit internally as well? Longword
| unary register operations take slightly longer than their
| word equivalents, even though the instruction is the same
| size in both cases.)
| mikepavone wrote:
| > I always assumed it's 16 bit internally as well?
|
| Correct, it's mostly 16-bit internally. Registers are
| 32-bit, but are split into 16-bit halves. The ALU is mostly
| 16-bit, but has a 32-bit shift register which is used for
| both shift/rotate operations and multiply/divide. There's a
| 32-bit adder in the "address unit" that's used for
| effective address calculations (including the LEA
| instruction), but it's much more limited than the ALU
| ebruchez wrote:
| The best part was that, no matter the size of internal or
| external buses, the programming model was 32-bit and
| extremely consistent. It was (and still is I suppose) so
| nice to write assembly code for it.
| agar wrote:
| I always thought that if the same amount of engineering and
| investment that went into overcoming the 8088 architecture
| instead was redirected into a more sane CPU architecture,
| development of the PC industry would have been accelerated by
| about a decade.
|
| I'm talking products like QEMM, Sidekick (and the whole
| "terminate and stay resident" industry), expanded vs. extended
| memory, and other massive engineering efforts by major software
| (Lotus, Ventura Publisher, etc.). Time spent overcoming the
| limitations of the 640K barrier, segmented memory, and similar
| design challenges could have been spent in more productive ways,
| as could be seen in the development of other ecosystems on a
| comparative shoestring budget.
|
| Granted I was an Amiga aficionado back in the late '80s/early
| 90's, so I'm comparing things like the ATI VGA Wonder (1988) to
| the Video Toaster (1990), or early efforts at GUIs (like GEM) to
| the multitasking OS of Amiga. But still, I think the point
| stands.
| mikewarot wrote:
| Oh man, 15 registers, each 32 bits wide, with indirect addressing
| modes... it would have been glorious! No more weird need to cram
| things into just the right registers to do a string operation.
|
| Not as nice as a PDP-11 processor, but damned close!
| klodolph wrote:
| Indirect addressing, including _memory indirect_ addressing,
| which takes a base address (register), an index (register), a
| size (immediate), two offsets (immediate), and an address
| stored in memory somewhere.
|
| You could, in one single instruction, struct B
| { int x, y, z; }; struct A { int a,
| b, c; struct B *ptr; }; void
| func(struct A *array, int i) { array[i].ptr->z = 3;
| }
|
| Unless I am remembering how it works incorrectly.
| mras0 wrote:
| Only supported on 68020+ though, but yeah think it would be
| something like move.l #3,([6,a0,d0.l*8],4) (scale only goes
| up to 8 though)
| bewaretheirs wrote:
| godbolt doesn't seem to think so.
|
| This is a little closer: https://godbolt.org/z/5K4MEYe31
|
| and IIRC there was also the "LEA" instruction ("Load
| Effective Address") which stored the computed memory address
| instead of fetching/storing to that address. And I believe
| some compilers would (ab)use that to do math as well (though
| this was complicated by the aX/dX register split)
| mras0 wrote:
| The addressing modes do exist on 68020+
| (https://www.nxp.com/files-
| static/archives/doc/ref_manual/M68... section 2.2), but I
| don't think any compiler will generate them (even with
| -mcpu=68020) as I think they're not actually faster than
| doing it the normal way (even if that costs a register),
| maybe slower, but I'd have to check the cycle counts.
|
| EDIT: Yeah, so if I'm not misreading MC68020UM the memory
| indirect mode is slower move.l
| #3,([6,a0,d0.l*8],4) ; 9 cycles best case
|
| vs. move.l 6(a0,d0.l*8),a0 ;4
| move.l #3,4(a0) ; 3
| marssaxman wrote:
| It _was_ glorious! It was the most fun I 've ever had with
| assembly language (though the fact that hand-written assembly
| still mattered back then probably had a lot to do with that,
| too).
| 13of40 wrote:
| No segment registers, as well. A byte of memory is just where
| it says it is, and you can access [n] and [n+100000] in one
| breath.
| int_19h wrote:
| But it also means that all your pointers are now 32-bit wide,
| no? On a machine where memory is measured in kilobytes, that
| is an expensive luxury.
| NikkiA wrote:
| Don't try just accessing a byte though, even though there are
| instructions for it it'll trap. I can't remember if _working_
| byte addressing got added in the 68010 or 68020.
| tom_ wrote:
| You could definitely access bytes? You couldn't do word or
| long accesses on odd addresses however. The 68000 doesn't
| have a pin for bit 0 of the address. (Byte accesses
| presumably fetch the word of interest and discard the 8
| unwanted bits.)
| tom_ wrote:
| You can't do [n+100000] - the displacement field for the
| equivalent addressing mode is 16 bits.
|
| I also wouldn't hold my breath while waiting for the 68000 to
| do _anything_... all the instructions are enormous, and they
| take ages to execute.
| bewaretheirs wrote:
| The register partitioning (eight "data" registers d0-d7 and
| eight "address" registers a0-a7, with a7 being the stack
| pointer) was probably the biggest wart.
| Findecanor wrote:
| I like to see it the other way around: the partitioning was a
| smart way of doubling the number of registers that could be
| expressed in a fixed-length 16-bit instruction word.
|
| There are many computational instructions that don't make
| much sense on addresses, especially if you have rich address
| modes to begin with. And if you'd need to, there was the
| "movea" instruction for copying between the register files.
| dboreham wrote:
| 68k was nicer than a pdp-11 because it had 32-bit addressing.
|
| Edit: well, 24-bit physically, but flat linear address space
| and an instruction set that permitted 32-bit addressing.
| jandrese wrote:
| Yes, and that "Only 24 bits of the 32 bit word are used"
| thing came back to bite Apple hard when the "32 bits for
| real" 68020 came out and the funny tricks they were pulling
| with the top 8 bits confused the processor.
| zackmorris wrote:
| 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 wrote:
| I'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 wrote:
| It'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-...) 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/
| dontlaugh wrote:
| Embarrassingly 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 wrote:
| one 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 wrote:
| I'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.
| convolvatron wrote:
| There is a whole class of communication optimal
| algorithms. And cache oblivious ones. You really
| shouldn't have to do what you're doing, and progress is
| being made.
| UncleOxidant wrote:
| I know, right? Just think about what could have been if IBM had
| selected the 68K. An assembly language that was actually pretty
| pleasant to program in. Motorola would probably be the Intel of
| now. Intel would maybe still be making memory (so kind of like
| Micron and probably similar in size).
| speed_spread wrote:
| I keep reading here great things about the 68k. What made
| Motorola diverge from it and invest in a whole new arch (88k)
| rather than keep pushing the 68k line? Intel succeeded in
| evolving x86 despite it being an originally subpar design,
| surely the 68k could have been taken further more easily?
| cmrdporcupine wrote:
| Lower sales. Bad management. And there was a consensus at
| that point that CISC was a dead-end and RISC was the
| future. Also, they did in fact take the 68k further
| (ColdFire) but too late, long after they had pushed their
| serious customers to PowerPC.
|
| Intel was making enough coin from x86 that they were
| reluctant to EOL it in favour of something RISC. Not that
| they didn't try. Multiple times (Itanium being the worst,
| though much later). But each time their replacement failed
| to ignite, and Intel pulled back from the brink and they
| pushed something that was a noticeable incremental
| improvement while keeping backward compatibility.
|
| And with the Pentium & the ISAs that followed they just
| seemed to pull a rabbit from a hat. They made the x86 CISC
| architecture scale in a way that pundits at least? didn't
| seem to think was possible.
|
| Motorola didn't invest in time in doing for 68k what Intel
| did for x86 with the Pentium. And they screwed over their
| customers as a result. They basically told everyone (Apple,
| NeXT, various workstation makers, etc.) to go to 88k. 88k
| was an architectural failure. So then they did PowerPC
| along with IBM and others. And people who used 68k
| previously either went PowerPC (Apple) or rolled their own
| RISC (Sun with SPARC, HP with PA-RISC, etc.) or just left
| the market entirely (Apple, Commodore).
|
| ColdFire is roughly to the 68k what Pentium II or so was to
| the x86 line. It's actually quite nice. They dropped a
| couple things from 68k but it's about 90% compatible, and
| can do a very effective software emulation to make itself
| 100%. But it got pushed basically only as a microcontroller
| or specialist (routers, ethernet switches, etc.)
| architecture. You can still buy them from NXP I believe.
|
| These days I don't like big-endian. And the separate
| address vs data registers seems weird now. But the 68k
| instruction set was overally very nice. I do imagine
| sometimes an alternate timeline where Motorola had rolled
| ColdFire out sooner as an MPU line for consumer stuff and
| Apple, etc. had used that instead of going PowerPC. I
| wonder what a 64-bit 68k would have looked like.
|
| IMHO Apple wasted a whole pile of engineering years getting
| MacOS classic to port over natively to PowerPC. It was
| extremely unstable and large parts were emulated 68k code
| for years. It might have saved them some unprofitable
| years, who knows? They seem to have finally learned the
| lesson and they own their own CPU now.
| temac wrote:
| > And with the Pentium & the ISAs that followed they just
| seemed to pull a rabbit from a hat. They made the x86
| CISC architecture scale in a way that pundits at least?
| didn't seem to think was possible.
|
| The Pentium was not great, not terrible. IIRC 2 ways
| superscalar in-order, quite faster than the 486 (also
| because of caches, better memory, faster and wider FSB,
| way better latencies for tons of instructions) but it
| would not have been enough if Intel had tried to just
| make it evolve slowly.
|
| Of course at the time and taking price and competition
| into account, it was quite good to make faster PCs. But
| by itself it only showed a limited capability for scaling
| x86.
|
| The Pentium Pro was the uarch that showed that scaling
| was possible. Even if they have been deeply refined
| across the years and generations (putting NetBurst
| appart, of course), most of the technics it introduced in
| the x86 world are still a foundation of how the current
| generation x86 cores work. The rabbit that came out of
| the hat was the result of quite a number of years of
| work, most of it parallel to the P5 dev. The Pentium II
| consolidated that with better support for consumer
| software of the time (with still copious amount of 16-bit
| code), and, logically, marketing for consumer hardware
| (with manufacturing progress and tricks allowing a price
| not too high).
| ChainOfFools wrote:
| > PA-RISC, etc.) or just left the market entirely (Apple,
| Commodore).
|
| Worth noting that had Commodore's astonishingly out of
| touch and schizophrenic corporate management not driven
| the company into the grave, the Amiga engineering team
| had already settled on PA-RISC as their next generation
| architecture as well, and I believe even had reached
| prototype stage on the vapors of cash renained in their
| final months of existence.
| bitwize wrote:
| > Intel was making enough coin from x86 that they were
| reluctant to EOL it in favour of something RISC. Not that
| they didn't try. Multiple times (Itanium being the worst,
| though much later).
|
| It seems as if VLIW with a sufficiently smart compiler to
| handle the instruction packing was the "fetch" Intel kept
| trying to make happen, but it wasn't going to happen
| (people kept stumbling on the "sufficiently smart
| compiler" bit). First with the iAPX 432, then the i860,
| then Itanium.
| ghaff wrote:
| At some point (maybe the 68040?), the 68K line started to
| decline in popularity and there was a significant
| contingent of the industry that was convinced that RISC was
| the future (not that they were really wrong). The big Unix
| system companies were mostly doing their own RISC designs
| and Motorola figured that they had a significant market in
| the second-tier players like Data General that weren't
| going to do their own RISC designs.
|
| Intel did try to do RISC unsuccessfully with the i860--
| which also had some sort of VLIW mode, which makes their
| later Itanium even harder to understand.
| pulvinar wrote:
| Well, not as pure as the PDP-11, sure, but it was actually
| nicer to program and use.
| tyingq wrote:
| That's really impressive, that the emulated M68K is socketed in
| the 8088 motherboard and talking to all the peripherals through
| it.
| gallier2 wrote:
| Take an Atari ST and you can see what a m68k PC could have been.
| Its operating system GEMDOS was a derivative of CP/M with
| comparable features of MS_DOS. The syscall even use the same
| numbers (trap #1 calls to GEMDOS map 1:1 on int 21H MS-DOS
| calls).
|
| This said, several hardware PC-emulators on the Atari did exactly
| the thing that article describes. PC-Speed added a NEC V30 that
| was soldered on the 68000 and could takeover the bus and the
| emulation only consisted on simulating the peripherals. It worked
| like a charm and thanks to the generous memory of the ST could
| even do some things better than real PC's (for example the 640K
| limit was in reality a 736K limit). Later versions used 286 and
| even 386sx cpu's.
| UncleOxidant wrote:
| I seem to recall that there was a software PC/MSDOS-emulator
| for the ST that was verrry slow (of course). Am I mis-
| remembering?
| kabdib wrote:
| GEMDOS was written from scratch (by Digital Research) and
| doesn't share any code or data structures with CP/M. Many of
| the BIOS and system calls were the same, but GEMDOS had
| recursive directories, etc.
| [deleted]
| grumpyprole wrote:
| But it's a derivative in the same sense that Linux is often
| called a derivative of Unix.
| cmrdporcupine wrote:
| Hah, funny, I just posted effectively the same comment
| elsewhere in this thread.
|
| Though as sibling comment correctly points out (and he'd know
| more than most, BTW) GEMDOS is more a CP/M-alike than a CP/M
| itself. There's really no or very little code shared in common
| with CP/M68k (both are under GPL now so you can go and look). I
| think the only thing shared between the two is the program
| loader source, and I might even be wrong about that.
|
| But yes I feel like this machine in this article should boot to
| a COMMAND.COM running on GEMDOS. Or at least CP/M68k. The
| source is available to make that happen fairly easily.
| renewedrebecca wrote:
| I bet it would be fairly easy to port a command line version
| of EmuTOS to this thing.
| ok123456 wrote:
| During the initial meetings about the IBM PC, didn't Microsoft
| pitch the idea of using the 68k?
| 13of40 wrote:
| Bill Gates claimed that at one of the Microsoft company
| meetings in the early 2000s.
| elvis70 wrote:
| Bill Gates confirmed this in an interview published in PC
| Magazine in 1997 [1]: ..."Once we convinced IBM to go 16-bit
| (and we looked at 68000 which unfortunately wasn't debugged at
| the time so decided to go 8086)"...
|
| [1]
| https://web.archive.org/web/20010823113747/https://www.pcmag...
___________________________________________________________________
(page generated 2023-05-12 23:01 UTC)