6 ms·

Does anyone know if a 16-bit port of Unix-like OS ever existed in the first place? What would the C ABI be in that case? I’m guessing: char: 8 bits sho

Does anyone know if a 16-bit port of Unix-like OS ever existed in the first place? What would the C ABI be in that case? I’m guessing: char: 8 bits short,int,long: 16 bits Anyone have experience working with such a system?

emidln 5y ago
Xenix (an official port of System 7) was available for Intel 286s from Microsoft. There were a number of Unix-like systems for 16 bit systems, and the Ancient Unixen were initially running on 16bit processors (notably the PDP-11). You can run 16bit unix in a simulator today.
- anyfoo 5y ago
  It was even available for 8086, XENIX 8086. Another 8086 UNIX at that time was PC/IX. I played around with them both, and they both have upsides and downsides.
ghostDancer 5y ago
Xenix from SCO and Microsoft. At least it ran on a 286. Can't answer about the C ABI.
benttoothpaste 5y ago
There were a few. - minix 1.0 could run on XT with a floppy disk - coherent version < 4 could run on AT 286 - Xenix had a 286 version as well
- a-dub 5y ago
  coherent on a 286 was my first experience with unix on intel hardware. good ol' mark williams corporation. i remember it had one hell of a doorstop book that they referred to as "the lexicon."
  - icedchai 5y ago
    I remember the book that came with Coherent 4.x. It was great! I already knew C, but learned a ton of POSIX / Unix-specific stuff from that book.
timeinput 5y ago
On a 16 bit cpu I worked on char, short, and int were all 16 bit words, long and long long were 32 and 64 bits, but doing math with 32 bit words required the C compiler to emmit instructions to manage the 32-bit operations. Also sizeof(long) was 2 and sizeof(long long) was 4.
- CyberRabbi 5y ago
  I was mistaken. I think long must be a minimum of 32 bits according to the standard
- ant6n 5y ago
  > Also sizeof(long) was 2 and sizeof(long long) was 4 Wait what? Doesnt that mean a byte somehow has 16 bits?
  - CyberRabbi 5y ago
    sizeof() is measured in number of chars, I.e. sizeof(char) is always 1. As he said, char was also 16-bit.
  - anyfoo 5y ago
    While you got an answer already, there was also a time where 8 bit wasn't standard yet, and computers existed in all kinds of word sizes. 18 bit, 36 bit, and even "variable size" (i.e. IBM 1401). The further back you go, the more it shatters what we consider "normal" and "essentially fixed" in today's computer world.
    - ant6n 5y ago
      Okay this must have been _some_ sort of 16 bit cpu, but i find it hard to believe any x86 cpu had a major c compiler with char having 16 bits.
      - timeinput 5y ago
        Yeah definitely was not x86. It was an embedded DSP
pinewurst 5y ago
Microport sold Unix System V for 286s.
icedchai 5y ago
Coherent probably qualifies: https://en.wikipedia.org/wiki/Coherent_(operating_system) https://en.wikipedia.org/wiki/Coherent_(operating_system) Around 1993 or so, before Linux took off, I ran it on a 386SX laptop with 3 megs of RAM. Supposedly earlier versions ran on the 286 but I never tried.
indymike 5y ago
Sure. SCO/Microsoft Xenix. You could buy a PC AT or compatible clone, hang 2-4 terminals off it (the console gave you one extra) and run point of sale, physician's office management software or accounting software. Terminals cost about 1/4 of what a 286 cost in 1986-1989 so you'd see a lot of it in small businesses, and there were a few chains that used it because they could use UUCP to send in data to the home office. Fun. Here's a link to the programmer's guide: http://www.nj7p.org/Manuals/PDFs/Intel/174391-001.pdf http://www.nj7p.org/Manuals/PDFs/Intel/174391-001.pdf pages 2:17-2:22 cover the pointer and data type sizes. Amazing how little things have changed... and how different things are at the same time.
- CyberRabbi 5y ago
  Exactly the type of thing I was hoping to see. Mind blowing the 286 could run a fully fledged Unix. I wonder what the process isolation story is, did everything run in the same address space? If so then were all binaries position-independent? Edit: answered my own question. So this is the obsolete segmentation isolation I’ve always read about!
  - indymike 5y ago
    > Edit: answered my own question. So this is the obsolete segmentation isolation I’ve always read about! Yep. It was amazing what you could do with it. 286 was a chip that outside Xenix, Coherent and a few other multiuser OSes never really was fully utilized.
mr_toad 5y ago
The big problem with early x86 machines was the lack of an MMU and process isolation.
- anyfoo 5y ago
  Though there were multiple solutions where the MMU sat outside the CPU, on the bus between 8086 and memory. That setup was common in general, but a bit less common for the 8086 specifically. Support wasn't perfect, often paging wasn't a thing, but isolation and protection in general worked somewhat reasonably.
GekkePrutser 5y ago
Like others have said: Minix and others did. I ran Minix for a while when I had a 386sx (wish was like a 16 bit 386). In particular it lacked the protected mode that Linux used heavily. So full 386 software didn't run on that. Minix was super fast but there was little you could do with it, sadly. Of course pretty much all Intel computers still run Minix today as part of Intel's management engine.
- Sunspark 5y ago
  It bothers me that the ME exists. A completely separate computer that can be remotely controlled and I can't turn it off. I'll be glad when there's more CPU competitors that don't have one of those, even if they are slower.
  - robertlagrant 5y ago
    That's why they're called "intel" :-)
  - CyberRabbi 5y ago
    My gut tells me that no cpu manufacturer can ever be trusted if intel cannot be trusted. What is hopeful to me are RISCV softcores running on FPGA. Will never beat CPU records but will likely be the best option available for private computing.
spijdar 5y ago
I'm surprised no-one has mentioned that UNIX from Bell Labs was first developed on a 16-bit system, the PDP-11. 1BSD and 2BSD were both consequently 16-bit, and it wouldn't be until a separate small team from Bell Labs ported it to the VAX in a release called "32V" that it became 32 bit at all. (This release and increase in word size revealed a lot of bugs in the 16 bit only Unix and C compiler -- I recommend reading the porting paper if this sort of thing interests anyone) Edit: Paper is here https://www.bell-labs.com/usr/dmr/www/otherports/32v.html https://www.bell-labs.com/usr/dmr/www/otherports/32v.html To answer your question from the paper, it appears all the other data types were 2 bytes, except for char, which was one byte. And long/float, which were handled specially, I believe by the PDP-11's floating point co-processor "C code for the PDP-11 uses the FP-11 convention for storing long integers"
- CyberRabbi 5y ago
  Could you provide a link to the porting paper? Would it be possible for you to summarize how process isolation worked on the PDP-11?
  - spijdar 5y ago
    Sure, I linked it in. I posted the first response from my phone, took me a bit to find everything on my computer... The PDP-11 has an MMU and supports what's essentially segmented memory (https://gunkies.org/wiki/PDP-11_Memory_Management https://gunkies.org/wiki/PDP-11_Memory_Management), with different address spaces for a kernel and for a userspace. It also supports a 22-bit "real" address space, hence when 2BSD and other "older" PDP-11 unixes can use up to 4MB of real memory (and 2.10BSD's kernel actually used more memory than could fit in a 16 bit address space at once -- needing to be manually chunked and loaded in/out of memory. In the release notes (http://www.krsaborio.net/bsd/research/1987/0715.htm http://www.krsaborio.net/bsd/research/1987/0715.htm) the authors said "Yes, [this is the last release] at least by us; quite frankly, we'd rather sacrifice our chance at heaven than look at a 16-bit machine again.", so it's about as nightmarish as it sounds. It doesn't support paging, though, so no real virtual memory. I'm not really sure how thorough the process isolation was -- I know in the early releases, there was basically none, and a bad user process would crash the whole machine. I believe by later models (the MMU did change over time) it was "good enough" to keep the userland from crashing the kernel, at least. Wasn't until 3BSD from Berkeley that proper virtual memory was added -- hence why the kernel's name was changed from /unix to /vmunix. Which is where the "vm" in "vmlinux" comes from, in case anyone's curious.
anyfoo 5y ago
You've got plenty of answers already, but here is a list of specifically 8086 UNIXes (or "UNIX-likes") that I remember. Some I have played around with quite a bit. - Coherent - XENIX 8086 - SINIX (technically on 80186, and derived from XENIX) - PC/IX - Minix86 One of the first things I usually do on an old but new to me system is run a small C program that just prints sizeof() of various types, including the ones you mentioned and pointers. Here it is on SINIX, which is the one I can currently run easiest (unit is multiples of sizeof(char) == 1, with normal 8 bit bytes): char: 1, short: 2, int: 2, long: 4, long long: 4, pointer: 2 So it's almost like you say, but long (and long long) are actually 32 bits. Standard pointers are 16 bit, which means they address within a segment. There is almost certainly also a way to specify 32 bit far pointers (seg:off), or maybe even 32 bit "huge" pointers (still seg:off, but normalized, so that comparisons work).

emidln 5y ago

Xenix (an official port of System 7) was available for Intel 286s from Microsoft. There were a number of Unix-like systems for 16 bit systems, and the Ancient Unixen were initially running on 16bit processors (notably the PDP-11). You can run 16bit unix in a simulator today.

anyfoo 5y ago
It was even available for 8086, XENIX 8086. Another 8086 UNIX at that time was PC/IX. I played around with them both, and they both have upsides and downsides.

ghostDancer 5y ago

Xenix from SCO and Microsoft. At least it ran on a 286. Can't answer about the C ABI.

benttoothpaste 5y ago

There were a few. - minix 1.0 could run on XT with a floppy disk - coherent version < 4 could run on AT 286 - Xenix had a 286 version as well

a-dub 5y ago
coherent on a 286 was my first experience with unix on intel hardware. good ol' mark williams corporation. i remember it had one hell of a doorstop book that they referred to as "the lexicon."
- icedchai 5y ago
  I remember the book that came with Coherent 4.x. It was great! I already knew C, but learned a ton of POSIX / Unix-specific stuff from that book.

timeinput 5y ago

On a 16 bit cpu I worked on char, short, and int were all 16 bit words, long and long long were 32 and 64 bits, but doing math with 32 bit words required the C compiler to emmit instructions to manage the 32-bit operations. Also sizeof(long) was 2 and sizeof(long long) was 4.

CyberRabbi 5y ago
I was mistaken. I think long must be a minimum of 32 bits according to the standard
ant6n 5y ago
> Also sizeof(long) was 2 and sizeof(long long) was 4 Wait what? Doesnt that mean a byte somehow has 16 bits?
- CyberRabbi 5y ago
  sizeof() is measured in number of chars, I.e. sizeof(char) is always 1. As he said, char was also 16-bit.
- anyfoo 5y ago
  While you got an answer already, there was also a time where 8 bit wasn't standard yet, and computers existed in all kinds of word sizes. 18 bit, 36 bit, and even "variable size" (i.e. IBM 1401). The further back you go, the more it shatters what we consider "normal" and "essentially fixed" in today's computer world.
  - ant6n 5y ago
    Okay this must have been _some_ sort of 16 bit cpu, but i find it hard to believe any x86 cpu had a major c compiler with char having 16 bits.
    - timeinput 5y ago
      Yeah definitely was not x86. It was an embedded DSP

pinewurst 5y ago

Microport sold Unix System V for 286s.

icedchai 5y ago

Coherent probably qualifies: https://en.wikipedia.org/wiki/Coherent_(operating_system) https://en.wikipedia.org/wiki/Coherent_(operating_system) Around 1993 or so, before Linux took off, I ran it on a 386SX laptop with 3 megs of RAM. Supposedly earlier versions ran on the 286 but I never tried.

indymike 5y ago

Sure. SCO/Microsoft Xenix. You could buy a PC AT or compatible clone, hang 2-4 terminals off it (the console gave you one extra) and run point of sale, physician's office management software or accounting software. Terminals cost about 1/4 of what a 286 cost in 1986-1989 so you'd see a lot of it in small businesses, and there were a few chains that used it because they could use UUCP to send in data to the home office. Fun. Here's a link to the programmer's guide: http://www.nj7p.org/Manuals/PDFs/Intel/174391-001.pdf http://www.nj7p.org/Manuals/PDFs/Intel/174391-001.pdf pages 2:17-2:22 cover the pointer and data type sizes. Amazing how little things have changed... and how different things are at the same time.

CyberRabbi 5y ago
Exactly the type of thing I was hoping to see. Mind blowing the 286 could run a fully fledged Unix. I wonder what the process isolation story is, did everything run in the same address space? If so then were all binaries position-independent? Edit: answered my own question. So this is the obsolete segmentation isolation I’ve always read about!
- indymike 5y ago
  > Edit: answered my own question. So this is the obsolete segmentation isolation I’ve always read about! Yep. It was amazing what you could do with it. 286 was a chip that outside Xenix, Coherent and a few other multiuser OSes never really was fully utilized.

mr_toad 5y ago

The big problem with early x86 machines was the lack of an MMU and process isolation.

anyfoo 5y ago
Though there were multiple solutions where the MMU sat outside the CPU, on the bus between 8086 and memory. That setup was common in general, but a bit less common for the 8086 specifically. Support wasn't perfect, often paging wasn't a thing, but isolation and protection in general worked somewhat reasonably.

GekkePrutser 5y ago

Like others have said: Minix and others did. I ran Minix for a while when I had a 386sx (wish was like a 16 bit 386). In particular it lacked the protected mode that Linux used heavily. So full 386 software didn't run on that. Minix was super fast but there was little you could do with it, sadly. Of course pretty much all Intel computers still run Minix today as part of Intel's management engine.

Sunspark 5y ago
It bothers me that the ME exists. A completely separate computer that can be remotely controlled and I can't turn it off. I'll be glad when there's more CPU competitors that don't have one of those, even if they are slower.
- robertlagrant 5y ago
  That's why they're called "intel" :-)
- CyberRabbi 5y ago
  My gut tells me that no cpu manufacturer can ever be trusted if intel cannot be trusted. What is hopeful to me are RISCV softcores running on FPGA. Will never beat CPU records but will likely be the best option available for private computing.

spijdar 5y ago

I'm surprised no-one has mentioned that UNIX from Bell Labs was first developed on a 16-bit system, the PDP-11. 1BSD and 2BSD were both consequently 16-bit, and it wouldn't be until a separate small team from Bell Labs ported it to the VAX in a release called "32V" that it became 32 bit at all. (This release and increase in word size revealed a lot of bugs in the 16 bit only Unix and C compiler -- I recommend reading the porting paper if this sort of thing interests anyone) Edit: Paper is here https://www.bell-labs.com/usr/dmr/www/otherports/32v.html https://www.bell-labs.com/usr/dmr/www/otherports/32v.html To answer your question from the paper, it appears all the other data types were 2 bytes, except for char, which was one byte. And long/float, which were handled specially, I believe by the PDP-11's floating point co-processor "C code for the PDP-11 uses the FP-11 convention for storing long integers"

CyberRabbi 5y ago
Could you provide a link to the porting paper? Would it be possible for you to summarize how process isolation worked on the PDP-11?
- spijdar 5y ago
  Sure, I linked it in. I posted the first response from my phone, took me a bit to find everything on my computer... The PDP-11 has an MMU and supports what's essentially segmented memory (https://gunkies.org/wiki/PDP-11_Memory_Management https://gunkies.org/wiki/PDP-11_Memory_Management), with different address spaces for a kernel and for a userspace. It also supports a 22-bit "real" address space, hence when 2BSD and other "older" PDP-11 unixes can use up to 4MB of real memory (and 2.10BSD's kernel actually used more memory than could fit in a 16 bit address space at once -- needing to be manually chunked and loaded in/out of memory. In the release notes (http://www.krsaborio.net/bsd/research/1987/0715.htm http://www.krsaborio.net/bsd/research/1987/0715.htm) the authors said "Yes, [this is the last release] at least by us; quite frankly, we'd rather sacrifice our chance at heaven than look at a 16-bit machine again.", so it's about as nightmarish as it sounds. It doesn't support paging, though, so no real virtual memory. I'm not really sure how thorough the process isolation was -- I know in the early releases, there was basically none, and a bad user process would crash the whole machine. I believe by later models (the MMU did change over time) it was "good enough" to keep the userland from crashing the kernel, at least. Wasn't until 3BSD from Berkeley that proper virtual memory was added -- hence why the kernel's name was changed from /unix to /vmunix. Which is where the "vm" in "vmlinux" comes from, in case anyone's curious.

anyfoo 5y ago

You've got plenty of answers already, but here is a list of specifically 8086 UNIXes (or "UNIX-likes") that I remember. Some I have played around with quite a bit. - Coherent - XENIX 8086 - SINIX (technically on 80186, and derived from XENIX) - PC/IX - Minix86 One of the first things I usually do on an old but new to me system is run a small C program that just prints sizeof() of various types, including the ones you mentioned and pointers. Here it is on SINIX, which is the one I can currently run easiest (unit is multiples of sizeof(char) == 1, with normal 8 bit bytes): char: 1, short: 2, int: 2, long: 4, long long: 4, pointer: 2 So it's almost like you say, but long (and long long) are actually 32 bits. Standard pointers are 16 bit, which means they address within a segment. There is almost certainly also a way to specify 32 bit far pointers (seg:off), or maybe even 32 bit "huge" pointers (still seg:off, but normalized, so that comparisons work).