4 ms·

16 bit programs used 16 bit addresses, generally speaking. Even with 32bit systems where you’d want more than 4GB RAM, application software still had 32 bit ad

by hnlmorg 5mo ago

16 bit programs used 16 bit addresses, generally speaking. Even with 32bit systems where you’d want more than 4GB RAM, application software still had 32 bit addresses (and thus 4GB memory limit). I think it was a lot more common for 8bit systems to allow for 16 bit addressing though. It’s been a while though. So hopefully I’m not misremembering things.

barrkel 5mo ago
You had to deal with two flavors of pointer, near and far. Far pointers came with segment selector, for accessing more than 64k. Your choice of memory model influenced the defaults. You might use near pointers for internal references in a module, and far pointers for external references.
- senfiaj 5mo ago
  I guess it was awkward to use languages that had higher level than assembly in order to write 16-bit programs that required more than 64KiB of memory. And also not quite portable, since they were all tied to x86 CPU. Those were messy times I guess. A somewhat similar story was 32-bit PAE, where the the CPU could address more than 4GiB physical memory, but software was still 32-bit and virtual addresses were capped at 4GiB. Linus was right that you must have more virtual memory (preferably 10+ times more) than physical, otherwise you have to jump through hoops. https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/ https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-ab...
  - trumpdong 5mo ago
    "portable" used to mean "able to be ported" rather than the "comes automatically ported if you just change compiler options" that it means today
    - hnlmorg 5mo ago
      All software is portable by that former definition. When people talked about portable before, they meant code that used an abstraction that was platform agnostic. And that’s how it’s still used today. It’s just we have better abstractions now so our expectations of what is “portable” have gotten stricter. Eg the P in POSIX (which is nearly 40 years old now) is “portable”. The point of POSIX was to provide common abstractions that one could build against to run on multiple different operating systems. It wasn’t about porting software, it was about preventing people from needing to constantly write platform-specific ports.
      - trumpdong 5mo ago
        It was about making software easier to port. You still couldn't necessarily just write software for all operating systems at once, but you had less porting work because less stuff was different because of the standardisation. So open(argv[1], O_RDONLY) works on all POSIX systems, but if you want to create a pseudoterminal, it's different on each, and if you want to create a container, they don't even use the same concepts.
        skissane 5mo ago
        > but if you want to create a pseudoterminal, it's different on each This is somewhat outdated information. POSIX.1-2001 added "posix_openpt" to create a pseudoterminal, and most POSIX implementations now support it–at least Linux, macOS, FreeBSD, NetBSD, OpenBSD, Solaris, z/OS, AIX, HP-UX, QNX, Minix and Cygwin do. (Of course, that's only true of current versions, if you go back a decade or more you'll find many of them hadn't implemented it yet.)
        hnlmorg 5mo ago
        But you’re now arguing the same point I am: Portable means low effort porting. Saying something “can” be ported doesn’t make it portable. People would port games from the NES to the Master System, to 8 bit Micros but in most cases they were effectively complete rewrites because there wasn’t any common abstractions between those platforms. Where as tools like POSIX provided abstractions to make code portable. As I said before, the only reason you think the term has changed over the years is because the abstractions have gotten better and thus people’s expectations for how much effort should be required to port have gotten stricter. But that doesn’t mean the term means something totally new. And by the way, I have authored portable terminal emulators and $SHELLs. ;)
andyjohnson0 5mo ago
> I think it was a lot more common for 8bit systems to allow for 16 bit addressing though. The 6502 and Z80 could use 16 bit addressing to access up to 64kb of memory. The 6502 had various other addressing systems, including iirc 8 bits, but none of them were wider tha 16 bits.
- JdeBP 5mo ago
  Psst! Let's blow their minds and tell them about the MC68008. (-:
- hnlmorg 5mo ago
  Oh yeah. I had loads of 6502 and Z80 systems (still do in fact). Can’t believe I forgot about that! Though in fairness, I do mostly now just use those systems to teach my kids BASIC
  - markus_zhang 5mo ago
    Just curious how do you teach kids BASIC. I’m sure my 6 year old won’t sit tight.
    - hnlmorg 5mo ago
      I usually start with game: guess the number. The computer generates a random number between 1 and 100. And you have to guess. When you’re too high, the computer says “too high” and likewise when you’re too low. It’s a great starter program because it teaches you strings (the output printed), integers, comparisons, conditionals, and iteration (you keep guessing until you get it right). And the whole thing only take around 20 lines (give or take). Then the kids plays a few games of that. And after the novelty of that game wears off, I tell them to customise it however they want. Eg different messages, different ranges to guess from, etc. It’s the same way I teach Python to primary school / kindergarten kids. The nice things about this is even if the kids don’t learn and remember the basic primitives, they still get a feel of “proper” coding in the same way that we did when we grew up. And they still get something they can play, even if the game itself is super basic (no pun intended). I’m not saying this will work with every child, though. All kids are different. But it’s been super successful both at home and in the schools I’ve helped out at.
cyberax 5mo ago
Not really. 16-bit programs on x86 used 32-bit pointers (effectively 20-bit due to the segment mechanism). 8-bit microprocessors used 16-bit addresses.
bluedino 5mo ago
And the 32-bit 4GB limit was often really "just a bit under 2GB" depending on the hardware, OS, etc
- vardump 5mo ago
  3/1 split was common, though. Especially towards the end of 32-bit era.

by hnlmorg 5mo ago

barrkel 5mo ago

You had to deal with two flavors of pointer, near and far. Far pointers came with segment selector, for accessing more than 64k. Your choice of memory model influenced the defaults. You might use near pointers for internal references in a module, and far pointers for external references.

senfiaj 5mo ago
I guess it was awkward to use languages that had higher level than assembly in order to write 16-bit programs that required more than 64KiB of memory. And also not quite portable, since they were all tied to x86 CPU. Those were messy times I guess. A somewhat similar story was 32-bit PAE, where the the CPU could address more than 4GiB physical memory, but software was still 32-bit and virtual addresses were capped at 4GiB. Linus was right that you must have more virtual memory (preferably 10+ times more) than physical, otherwise you have to jump through hoops. https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-about-pae/ https://cl4ssic4l.wordpress.com/2011/05/24/linus-torvalds-ab...
- trumpdong 5mo ago
  "portable" used to mean "able to be ported" rather than the "comes automatically ported if you just change compiler options" that it means today
  - hnlmorg 5mo ago
    All software is portable by that former definition. When people talked about portable before, they meant code that used an abstraction that was platform agnostic. And that’s how it’s still used today. It’s just we have better abstractions now so our expectations of what is “portable” have gotten stricter. Eg the P in POSIX (which is nearly 40 years old now) is “portable”. The point of POSIX was to provide common abstractions that one could build against to run on multiple different operating systems. It wasn’t about porting software, it was about preventing people from needing to constantly write platform-specific ports.
    - trumpdong 5mo ago
      It was about making software easier to port. You still couldn't necessarily just write software for all operating systems at once, but you had less porting work because less stuff was different because of the standardisation. So open(argv[1], O_RDONLY) works on all POSIX systems, but if you want to create a pseudoterminal, it's different on each, and if you want to create a container, they don't even use the same concepts.
      - skissane 5mo ago
        > but if you want to create a pseudoterminal, it's different on each This is somewhat outdated information. POSIX.1-2001 added "posix_openpt" to create a pseudoterminal, and most POSIX implementations now support it–at least Linux, macOS, FreeBSD, NetBSD, OpenBSD, Solaris, z/OS, AIX, HP-UX, QNX, Minix and Cygwin do. (Of course, that's only true of current versions, if you go back a decade or more you'll find many of them hadn't implemented it yet.)
      - hnlmorg 5mo ago
        But you’re now arguing the same point I am: Portable means low effort porting. Saying something “can” be ported doesn’t make it portable. People would port games from the NES to the Master System, to 8 bit Micros but in most cases they were effectively complete rewrites because there wasn’t any common abstractions between those platforms. Where as tools like POSIX provided abstractions to make code portable. As I said before, the only reason you think the term has changed over the years is because the abstractions have gotten better and thus people’s expectations for how much effort should be required to port have gotten stricter. But that doesn’t mean the term means something totally new. And by the way, I have authored portable terminal emulators and $SHELLs. ;)

andyjohnson0 5mo ago

> I think it was a lot more common for 8bit systems to allow for 16 bit addressing though. The 6502 and Z80 could use 16 bit addressing to access up to 64kb of memory. The 6502 had various other addressing systems, including iirc 8 bits, but none of them were wider tha 16 bits.

JdeBP 5mo ago
Psst! Let's blow their minds and tell them about the MC68008. (-:
hnlmorg 5mo ago
Oh yeah. I had loads of 6502 and Z80 systems (still do in fact). Can’t believe I forgot about that! Though in fairness, I do mostly now just use those systems to teach my kids BASIC
- markus_zhang 5mo ago
  Just curious how do you teach kids BASIC. I’m sure my 6 year old won’t sit tight.
  - hnlmorg 5mo ago
    I usually start with game: guess the number. The computer generates a random number between 1 and 100. And you have to guess. When you’re too high, the computer says “too high” and likewise when you’re too low. It’s a great starter program because it teaches you strings (the output printed), integers, comparisons, conditionals, and iteration (you keep guessing until you get it right). And the whole thing only take around 20 lines (give or take). Then the kids plays a few games of that. And after the novelty of that game wears off, I tell them to customise it however they want. Eg different messages, different ranges to guess from, etc. It’s the same way I teach Python to primary school / kindergarten kids. The nice things about this is even if the kids don’t learn and remember the basic primitives, they still get a feel of “proper” coding in the same way that we did when we grew up. And they still get something they can play, even if the game itself is super basic (no pun intended). I’m not saying this will work with every child, though. All kids are different. But it’s been super successful both at home and in the schools I’ve helped out at.

cyberax 5mo ago

Not really. 16-bit programs on x86 used 32-bit pointers (effectively 20-bit due to the segment mechanism). 8-bit microprocessors used 16-bit addresses.

bluedino 5mo ago

And the 32-bit 4GB limit was often really "just a bit under 2GB" depending on the hardware, OS, etc

vardump 5mo ago
3/1 split was common, though. Especially towards the end of 32-bit era.