Hacker News Reader

Comment by wewewedxfgdf | Hacker News Reader

I seem to recall at the time that flat memory was self evidently a better idea. It's not like people were sitting around going "gee I can't think of any better way to do memory addressing that this" until some genius suggests "how about flat?!?!?" Everyone knew flat was best but were stuck with 8086 crap.

View on HN

I was drooling over the MC68000. I had a pre-release reference manual from 1979 and it was the most awesome chip around. Atari and Commodore and Apple used it after their 6502 systems. Arcade games used it after their 6502 and 6809 days. The only reason x86 became popular was because IBM put it in the PC - not for any technical reasons.

A 68k was roughly double the cost of an 8086, plus the additional cost for the rest of the supporting chips.

The PC was intended to be cheap and was competing with 8 bit machines. Being 16/20 bit made it already high end.

If you wanted 24 or 32 bit, IBM had many other machines to sell you. Or you could just buy a VAX.

Not entirely self-evidently. Position independent code was slower at the time and avoiding having to patching function addresses at load time is a net win.

More importantly, there’s backwards compatibility. By the time the 8086 came out, people had spent serious money on getting binary-only software (WordStar cost hundreds of dollars, for example). “Buy this computer, and you can keep running the software you paid for, but faster” was a good selling point.

I wonder why couldn't Intel simply introduce single 'offset' register for apps ported from 8080, and make all other registers 20-24bit. Why bother with 4 different registers and all that segmentation nightmare?

Lots of benefits to a word size a power of 2.

Very few benefits to a clunky 24 or 20 bit word size; now it costs more and is a bizarre boutique architecture in a world where it needs to compete with 8 bit Z80s and 6502s.

A single one would require a ported app to understand that it worked with bigger registers in order to take advantage of the bigger address space. Some really old computers did work like that, but to allow several apps to coexist in memory, not to give each app more addressable memory.

The segment register solution does both almost for free in most cases. Code gets a segment, data gets a segment, stack gets a segment... and you are free to use all of memory if you bother to use the ES register. In many cases, that could be isolated to a small piece of the program so that was also quite cheap.

As someone who wrote code in assembler, Pascal, and C for those machines: it wasn't at all a nightmare. It was quite easy and simple.

Personally I enjoyed writing assembly with segments. You can have 64k of code, 64k of data and 64k of stack without trying. So long as no individual data structure is larger than 64k there is no essential difficulty working with 16 bit pointers.

When I think back I think it would be fun to have a hierarchical structure where composite data structures (think an array or hash map) are referred to with a pointer that goes into the segment register and you index inside a data structure with a regular pointer.

Lots of 8086 code was written that way. You’d use the segment register on paragraph alignment and basically take advantage of the << 4 + logic.

This code was a nightmare to port to protected mode 80286 so it went away by the Windows 3.1 era.

I went from a 6809-based Color Computer 3 circa 1987 to a 80286. I am kicking myself today because my Uncle Bob told me the job that paid me $1,200 to get a new machine created upwards of $60,000 of value so I could have asked for enough to get a 386!

I was told not to waste any time with 80286 protected mode by all the experts I talked to. I can't complain a lot because that 80286 was crazy fast. Fast enough that when I got another job to develop some software for a teacher at my school I was able to run a Z80 emulator to develop for CP/M and get performance several times better than any real Z80!

I loved programming it too, the 286 had some 16-bit data paths that the 8086 didn't have which I took advantage of in assembly and in copy/move/zero routines that I used with Turbo Pascal which I thought was a much nicer language to C but when I got to college I switched to C because it was portable to the Sun 68k and later SPARC machines we had.

Flat memory was a better idea but it wasn't a cheaper idea, and cheaper beats good. A casual Googling shows a price of $2,880 for a IBM PC in ~1982 dollars versus $8,900 for a Sun Microsystems Sun-1 with a MC68000.

That was just Sun's market segment.

Also from a casual Google, an IBM PC launched in 1985 (picking the XT 5160-078 as an example) was around $4,995 at launch. Compare that to two 68000-based computers also launched in 1985: the Amiga 1000 launched at $1,295 and the Atari 520ST launched at $600.

These computer system prices - Sun, IBM, Commodore, Atari - came from the market segments the manufacturers aimed to sell to, rather than a cost saving enabled by cumbersome memory models.

The cumbersome memory model is just a historical accident; the 8086 designers wanted 8080 backwards compatibility so they could sell to former 8080 users, IBM did not require this. IBM would've picked the 68000 had it been "production ready" at the time, they did not reject flat memory on cost grounds!

Are you sure IBM didn't care about 8080 compatibility? The PC was released in August 1981, a full 4 years before any of the other machines you speak of. That XT 5160-078 you speak of is a cost-reduced model with no hard drive from IBM, allowing dealers to install a compatible hard drive from a different supplier.

By 1985, the PC AT (286) had already been out since August 1984. And the original XT was October of 1983. And the XT itself is literally the same as a PC with more expandability: 8 slots instead of 5, beefier PSU, room for a hard drive.

It's unclear if IBM or for that matter anyone would have been able to start designing a 68000-based machine and bring it to market by the fall of 1981. Sun brought the Sun 1 to market in May 1982, so about 9 months later, and with a much higher price.

And what did the Sun run? UNIX. What did IBM run? Quick ports of the last several years of CP/M software made possible because DOS 1 was specifically designed to implement a CP/M-like API, and the 8086 was specifically designed to allow porting of 8080 assembler code directly to small model 8086 code.

I picked 1985 specifically because of the Amiga/Atari 68000 machines, to show that it's not about price. Had Sun wanted to target the games-machine market, they could've designed for, built and sold a $600 machine based on a 68000 in 1981. Their pricing was because they went for the UNIX workstation market; they also designed and produced their own custom MMU because Motorola's 68851 didn't work correctly for them

Motorola were selling 68000s for $125 each. Steve Jobs talked them down to around $15 each. (Macintosh launch price: $2,495 in 1984) Memory model did not dictate price. Target market and vendor management did.

IBM would have been entirely capable of launching a TMS9900-based PC or a 68000-based PC, had these chips been in full production in 1978. The software and OS for the IBM PC was an afterthought, IBM settled on the CPU first. Had they picked the 68000, they'd have been contracting out for 68000-based OSes.

https://spectrum.ieee.org/the-inside-story-of-texas-instrume...

> Selection of a 16-bit microprocessor by the IBM team couldn’t have been much of a debate. The Motorola 68K, as it was later known, was undoubtedly the hands-down winner. It had the largest logical address space, which was even more important than the minimum 16-bit internal architecture. It was also easily expandable to a full-fledged 32-bit architecture.

> So why aren’t we all using 68K-based computers today? The answer comes back to being first to market. Intel’s 8088 may have been imperfect but at least it was ready, whereas the Motorola 68K was not. And IBM’s thorough component qualification process required that a manufacturer offer up thousands of “production released” samples of any new part so that IBM could perform life tests and other characterizations. IBM had hundreds of engineers doing quality assurance, but component qualifications take time. In the first half of 1978, Intel already had production-released samples of the 8088. By the end of 1978, Motorola’s 68K was still not quite ready for production release.

So it wasn't about architecture, and it wasn't even about price. It was about time-to-market. The 8088 was in full production and the 68000 was not quite there, at precisely the time IBM wanted to create a PC. The 8088 might've been even quicker to market had they left out the memory segmentation, but Intel had their own business reasons (wanting to sell to existing 8080 customers) for adding it.

-- Everyone knew flat was best but were stuck with 8086 crap.--

This! Thats one of the most interesting things to me: Actually very often in the IT-world, the worst competitor won the race while better solutions were known and available: Microsoft, Intel etc.

Esp. that MS won for decades while making mainly a very bad OS, though they have some good enterprise products.

How would the world look, if Unix/BSD would have won this race?

Being technically best has long been known to not be correlated to market success in the way that makes logical sense to technical people who feel confused about this.

I really wonder if Unix is best we can do. Or is it also worst? So in the end two of the worst options won. It did make sense back in time. But could it have been replaced with something better later?

>> two of the worst options won

What do you mean, which are the two? Sure, Windows is crappy by Linus and MacOS? They are both awesome.

There are many crappy design decisions in Unix, Posix, Linux, MacOS, that have been known and worked around for decades (see the Unix Hater's Handbook). One example would be async IO, which has been famously bad in Unix, and Linux alone has tried 2 different generations of solutions - with the newer one, io_uring, being suspiciously similar to Windows' decades old IOCP. Fork/exec is infamous as a needlessly complex process creation API, requiring huge effort in the kernel just to handle the most common case of simply launching a new process. The traditional Unix security paradigm of simple user based file permissions is extremely weak and has required numerous solutions on top to handle realistic security scenarios - e.g. to protect a user's files from being tampered in unexpected ways by a process launched by that user (SELinux, jails, namespaces, etc).

I agree that Windows is crappy, but that doesn't mean that Linux and MacOS aren't also crappy in their own ways (not to mention iOS, Android).

Especially the enshittification over the decades: All the bloat (XBog Game Icon on Win Server - really?), their update politics tangled with higher hardware specs for running the same stuff slower than before.

I do not understand how can one crash their own product/baby that way - and no, this must be Hanlors Razors: They are doing it with (sophisticated) intend, not by accident (or coincidence)

Linux is only used as a kernel temporarily until GNU is finished.

You mean GNU Hurd, I guess.

The operating system was going to be called GNU.

Don't open this can of worms. (-: There were endless discussions of this in the 1990s. Years's worth.

Scroll down to the 'What Is the Hurd?' section of this announcement post from 1996 and pay particular attention to its first and last sentences. That's the allusion here.

* https://groups.google.com/g/gnu.announce/c/d0N2mLo5dxk/m/bDq...

"Better" is not one dimensional scale

Adding more features to OS is for some use cases a benefit, for other it's a barrier. For one it might be less work to get what you want ,for other it might be more code between you and hardware that just slows it down

Unix-like simplicity is exactly that, for some use cases directness is a benefit, for others it means extra work to do on top to get what you want.

If you just want a house, getting a raw foundation to work with is a lot to build on top, you have to bring the rest of the walls up yourself.

But if you want exactly the house you want, getting entirely different house to start with and changing it is far more work than starting from simple foundation and building up.

Overall unix "here is relatively simple operating system that doesn't force you but needs some things to be built on top to hit your use case" probably IS the best abstraction, despise not being "best" at really anything. There is reason we build houses from concrete and wood, and not carbon fiber and titanium alloys

There have been some very nice OSes in the past (e.g. AmigaOS, BeOS, QNX, Plan 9) that all failed to the Wintel juggernaut. MacOS only just made it out alive.

I wouldn't say Unix itself is the best. It suffered a war between competing implementations pushing their own proprietary components. POSIX is the compromise.

But, ultimately, what is good about it today is not so much "Unix" (the proprietary OS from Bell Labs and its heritage), but specifically Linux and the BSDs. Why? Because they are actually open. They are freedom incarnate. You can add anything you like to them, today, without asking any permission. Not just their kernels, but their userlands too (Linux obviously varies by distro here). There's even a chance you can get your changes adopted upstream (unless it's GNOME), much more than you'd ever get from a proprietary company's OS.

So, while there's always room for improvement on the technical aspects of the OS, the social and political aspects of Linux and the BSDs make them the best we can achieve as a society.

There was a Microsoft operating system for protected mode 80286 in 1983. It was Xenix 286; it was basically 7th Edition Unix without the branding; and it was touted as the multiuser operating system that MS-DOS would be the gateway to. How would the world look if Microsoft had won the race? (-:

A PC with DOS was cheaper than a PC with Xenix, let alone a typical Unix machine. Also much easier to learn to use.

Macs also existed but were expensive. The PC with DOS was both powerful and cheap.

Flat is not necessarily a better idea. In 1978, a 32 bit CPU would be stupidly expensive. The use case for > 64k was to simply have code and data split apart, and also have some MMIO, so basically 192k-256k of addressing needed.

Segmentation meant programs could remain essentially 16 bit with all the benefits to that like smaller code size.

Except than later we returned to a sort-of segmented memory. That is of course paging, our programs allocates pages of memory that are a fixed size (4096 bytes) and are arranged in memory or in swap space how the OS decides.

We just have the illusion of a "flat" memory model, but it's not really flat, the CPU and the operating system does an important job in translating our flat memory model in something that is not flat at all. All that address translation work could have been avoided if we accepted to not have a flat memory model and be aware that our memory is divided in pages.

Basically we are doing in hardware the job of managing a non flat memory space that the programmer, or well, the compiler (or these days you would say the AI agent) could probably to better because it knows how to allocate things to avoid being them on page boundaries, and all of this to give the illusion to the programmer that it's working with a flat memory (except when it does something wrong and gets a segmentation fault, that, as the name suggests, is an hint that at the end the memory is not really flat).

In turn though, the thinking needed to handle non-flat memory is a complexity that most programmers cannot handle - and even those who could probably should spend their brain power on the complex parts of their program not managing memory. Best to leave that hard part to a few experts instead of make everyone understand it.

The above is very similar to the argument that you should use a garbage collected langauge.

Anyone writing an algorithm that needs to be high speed has to start thinking about caches and so forth. So it’s not exactly obsolete.

Back in 1980 most programs were being written in interpreted languages that did all the hard work of memory for you - just like today.

Paging is not part of the CPU architecture. On CPUs of the time the MMU that brought paging to the party often was a completely separate peripheral that the CPU interacted with to gate access to RAM. By contrast segments are an integral part of the CPU instruction set and your code either has to limit itself to 64KB or your application had to be aware of and include logic to manage segments.

As an aside, the memory model is flat, it's just not physically linear when implementing virtual memory addressing.

Reply on news.ycombinator.com