Back in 1983, my elementary school was a part of a Logo pilot program. We had a lab of Commodore 64's that I had free run of (my mom was a teacher there), and it's why I do what I do all these years later.
What I find interesting it that it's not just programming, specifically. Logo is a highly interactive and dynamic language (a relative of Lisp), and that influenced the way I think about writing code. Seymour Papert did a lot for me, albeit highly indirectly.
There is no such thing as a "2MB program".... all you have is a program composed of <=64K segments, which are easy enough to fit into the hole.
If you do need something approaching a 2MB block of memory, you don't need a contiguous range of memory, what you need is a contiguous range of selectors, which is a different (and probably easier) problem to solve.
but without virtual memory you can't move them around and so program that wants to allocate 2MB of 64k segments can't run if there is no 2MB continuos hole
I should preface this by saying I'm taking about x86 segmentation in general. On the 8086 you're right, but the 8086 can't address 2MB of memory to begin with. On the 80286 in protected mode, the situation is different in the way I'm about to describe.
The memory itself doesn't have to be contiguous.
2MB of 64K segments maps to 32 segments. So you need 32 locations in physical memory capable of storing 64K.
The programming model for addressing that block of memory necessarily includes both segment selectors and offsets. The segment selectors are indices into a segment table that contains the base address of each of the 32 segments. As long as the segment selectors themselves can be allocated contiguously in the segment table, you have enough to be able to compute which segment you need for which address in the 2MB range. It's the indirection through the segments table that maps it to physical addresses that do not need to be contiguous.
And this is the problem, it was very painful just to walk through a 200 KB buffer. This required compiler/runtime tricks, different selector increments in real vs protected mode, and special pointer types. Paging later made this kind of thing look like one flat array, a thing segmentation could not: making non-contiguous physical RAM appear contiguous to the program.
> And this is the problem, it was very painful just to walk through a 200 KB buffer. This required compiler/runtime tricks, different selector increments in real vs protected mode, and special pointer types.
Most of that could be (and often was) hidden by the tooling. If you needed to bypass it, you could, but you didn't need to. That's not very different from today... there's a lot of hidden magic that can be bypassed if you need to for whatever reason.
I'd argue that these are useful engineering abstractions that made the best of a less than ideal situation. (The reality of the world being that there are no "ideal" situations... you have to work with what you have at the moment to solve the problem you have. These days, I'd argue that a pointer into a 'flat' memory space is counter productive to the extent it hides issues around cache hierarchy, NUMA, etc. In 1986, we had to worry that a flat memory space looked discontiguous. In 2026, we have to worry the a discontiguous memory space looks flat.
OK, but we spent a decade having to worry about this garbage, until the tooling finally caught up. You always had to keep it in the back of your mind if you wrote PC software. Even if you just ran PCs, you had to worry about the compatibility between your OS, your "DOS extender", and your programs.
There were literally millions of man-hours wasted on segment registers. A kludge that helped Intel conquer the world, but what a filthy, disgusting architecture, and what a waste of everybody's time and brain power.
> OK, but we spent a decade having to worry about this garbage, until the tooling finally caught up.
This was less about tooling than it was about economics - there was 32-bit hardware available in the personal computer space in 1984, if not before. The issue was cost. In today's currency, a 32-bit capable Mac was $8,000 with 128K. The first 32-bit capable PC was closer to $20,000.
That's a heavy lift in a world where a segmented architecture machine costs a fraction of that amount, runs software you might already have, and works the same way as your co-worker's machine.
> There were literally millions of man-hours wasted on segment registers.
A software developer in 1986 was not forced to deal with segment registers... but they often chose to deal with them to gain access a (much) bigger audience of potential customers for their software.
> A kludge that helped Intel conquer the world, but what a filthy, disgusting architecture, and what a waste of everybody's time and brain power.
The other side of the coin is that (for reasons I state above), segmented architectures got more capable software into more hands more quickly. It arguably did a lot for end users.
> I had to use it to do image processing on a 256MB image buffer back in the 1980s in assembly language.... Give me a flat 32 bit memory address space any day (e.g. MC68000 around the same time.)
Huh?
There were no segmented x86 machines capable of addressing 256MB of RAM, aside from the 386 (maybe).
If you had a 386 and the $130K of memory your statement implies, you probably also could afford a Unix (or something else) license to get to that 32-bit address space. (If you weren't doing it all in memory, then you're having to depending on paging stuff out to disk, implying you either have a real OS or a flat memory model isn't enough to save you since you're manually having to page stuff to disk and back anyway.)
That's a super strange scenario you're describing.
Probably talking about swapping it in from some external datastore. These days you would open the file and dump it into a single buffer and rip across it, and not even really stress about it. Even 256 meg of hard drive. That would have been impressively expensive in the 80s.
Back then you had to chunk it out and fiddle with the offsets. Even then you still would have had to manage loading out the next chunk.
If my memory is right 1MB of memory in the early 90s was like 200-300 per meg. Would have to dig up a computer shopper and look.
> Even 256 meg of hard drive. That would have been impressively expensive in the 80s.
I only have a couple reference points around this scale:
My dad's company had a system set up with a searchable index of a bunch of legal testimony. It was a Compaq Deskpro 386 running Unix with an attached 1GB disk. The 1GB disk set up was as big as the machine itself.
A few years later, I worked with a Cyber mainframe equipped with around 30GB of total attached disk storage. The disk array literally filled a room.
256MB disk on an 80's PC would have definitely been quite a bit.
I remember my dad bought a 500MB hard drive for our Apple IIgs. It cost like $500-600 as I recall, not cheap by any means. I remember thinking that no way would we ever fill it up - which, to be fair, we never did. 500MB would fill up instantly now, but programs and data were so much smaller back then that it lasted until the computer eventually stopped being used.
That would make more sense. I was trying to imagine what sort of (custom?) hardware would accommodate that amount of memory back then. That was large storage even for mainframes the time. (The Cray 2 in the mid-1980's had 2GB, which was considered notably large.)
The 8086 was a stopgap measure to accommodate the fact the iAPX432 was in the middle of turning into the disaster it did. Given the engineering resources and timelines involved in the 8086, it wasn't a bad compromise approach.
> But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming
>
> "Oh if developers would just..." They won't. They haven't. And they will not ever.
8086 real mode programming in the mainstream lasted from 1981 until 1991 or so. The last 35 years have 32-bit (and later 64-bit) flat model addressing with pages for the most part. Seems like a reasonable transition period, really.
> In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough)
Part of the reason they liked the segmented model is that it was possible to set the segments to the same value and then ignore them entirely. That gave a programming model for the 8086 that was sufficiently close to the 8080 that it was possible to use a sort of cross assembler to do something like what you suggest. You could then opt into 8086 specific instructions and segmentation as you needed. (Which took a few years... the first IBM PC's shipped with as little as 16K of RAM.)
I asked Claude to add support for multiple lights to my toy ray-tracer. It correctly added the support and then suggested adding colored lights to make it easier to diagnose. It felt more like a colleague making a useful suggestion than any sort of pure engineering tool.
I think there are a couple questions you need to ask yourself - the first is why is it hard for you to be alone? You're the one person you're stuck living with for your entire life - it shouldn't be hard to be alone with yourself. That's where it began. That's where it will end.
You mentioned you have a therapist - this is something you might wish to explore with them.
The second question is related - what are you looking for in the "not alone"? What do you want? What would bring you peace? Are you looking for a relationship? A friend? Sex? etc? While you have to be comfortable with yourself, part of that comfort is knowing and being confident in what you're looking for. It may be that the world won't or can't provide it, but that's why I put this question second.
The final point I'll make is that there's nothing stopping you. You're an adult... within the constraints of the laws of your society, you CAN do what you want and there's nothing stopping you. It may not go the way you want, but it might, and wouldn't it be fun to try?
I like being alone. I'm good at being alone. I was an only child, often left alone , and I have lived alone (although dated a lot) for 20 years.
But if you put me in OPs situation, it would easily be tough. Working from home, living alone, totally lost your social circle possibly, AND sad over a recent breakup probably. Thats a prime recipe for problems even for people that do enjoy being alone for the most part.
What I find interesting it that it's not just programming, specifically. Logo is a highly interactive and dynamic language (a relative of Lisp), and that influenced the way I think about writing code. Seymour Papert did a lot for me, albeit highly indirectly.
https://mschaef.com/c64
reply