segmentation

40 views
Skip to first unread message

muta...@gmail.com

unread,
Jul 9, 2021, 9:04:19 PMJul 9
to
The more I look at the 8086, the more I am happy
that segmentation was the correct technical
solution to cope with machines that still had a
16-bit processor and registers, but had more than
64k memory available to them. I just would have
made the segment shift flexible instead of telling
everyone that "4" was being set in stone.

I believe they made machines with a 32-bit x86 but
more than 4 GiB of memory too. Or there was at
least the theoretical option to do so. And I think it
would be good to set up the required infrastructure
for this generic problem in computer science
regardless of actual processor or actual number of
bits in registers or shift value.

It seems to me that the tiny/small/compact/medium/large/huge
would be retained.

The C language doesn't need to change in order to
accommodate this. The onus is on the C programmer
to select the appropriate memory model.

It seems that only a fairly slight adjustment to
MSDOS is required to accommodate this.

And then a slight adjustment to Windows to support
the extra API calls required by 32-bit huge memory
model programs who need to know how to adjust
the segment register. Which may be a selector
instead???

BFN. Paul.

muta...@gmail.com

unread,
Jul 10, 2021, 6:31:06 PMJul 10
to
On Saturday, July 10, 2021 at 11:04:19 AM UTC+10, muta...@gmail.com wrote:

> And then a slight adjustment to Windows to support
> the extra API calls required by 32-bit huge memory
> model programs who need to know how to adjust
> the segment register. Which may be a selector
> instead???

Alex explained a scheme to map out 80286 selectors
so that they covered the 16 MiB. That can be considered
a segment shift too. My calculation is that that would
be a 8-bit segment shift.

I'm wondering whether any 32-bit x86 processor had
the same ability. ie since it is a 16:32 address, can you
address more than 4 GiB of memory?

Thanks. Paul.

muta...@gmail.com

unread,
Jul 12, 2021, 9:38:19 AMJul 12
to
On Sunday, July 11, 2021 at 8:31:06 AM UTC+10, muta...@gmail.com wrote:

> Alex explained a scheme to map out 80286 selectors
> so that they covered the 16 MiB. That can be considered
> a segment shift too. My calculation is that that would
> be a 8-bit segment shift.

Actually, on both the 80286 and the 80386, the OS should
make the effective segment shift for 16-bit applications
dependent on the amount of memory installed.

If you have 4 GiB of memory installed, that is when you
should be using 16-bit shifts. Or if there is a shortage
of selectors, then that would be a reason to go to
16-bit shifts earlier.

BFN. Paul.

Rod Pemberton

unread,
Jul 12, 2021, 11:27:31 AMJul 12
to
On Fri, 9 Jul 2021 18:04:18 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> The more I look at the 8086, the more I am happy
> that segmentation was the correct technical
> solution to cope with machines that still had a
> 16-bit processor and registers, but had more than
> 64k memory available to them. I just would have
> made the segment shift flexible instead of telling
> everyone that "4" was being set in stone.

They would've been wiser to split a 32-bit address across two registers
instead of using a 4-bit shift and add. That would've allowed for an
easier transition to 32-bit.

If you want to read about some of the problems transitioning to 32-bit,
see the 68000 micro-procesor which had 24-bit addresses. Programmers
found uses for those upper bits ... The 68000 series migrated to
32-bit addresses and couldn't execute older software.

Sound familiar? E.g., x86 A20? (No foresight.)


--
The Chinese have such difficulty with English ... The word is not
"reunification" but "revenge".

Scott Lurndal

unread,
Jul 12, 2021, 1:14:37 PMJul 12
to
Rod Pemberton <noe...@basdxcqvbe.com> writes:
>On Fri, 9 Jul 2021 18:04:18 -0700 (PDT)
>"muta...@gmail.com" <muta...@gmail.com> wrote:
>
>> The more I look at the 8086, the more I am happy
>> that segmentation was the correct technical
>> solution to cope with machines that still had a
>> 16-bit processor and registers, but had more than
>> 64k memory available to them. I just would have
>> made the segment shift flexible instead of telling
>> everyone that "4" was being set in stone.
>
>They would've been wiser to split a 32-bit address across two registers
>instead of using a 4-bit shift and add. That would've allowed for an
>easier transition to 32-bit.

A waste of scarce resources (registers). Consider also the
required logic (and the process in the 1980s - the 8080 was 6um,
8086 was 3um). Today, 5nm is in production and 3nm is coming soon,
that's 1000 times finer).

Even in 1978, when the 8086 was launched, segementation was recognized
as a poor choice for memory management.


>
>If you want to read about some of the problems transitioning to 32-bit,
>see the 68000 micro-procesor which had 24-bit addresses. Programmers
>found uses for those upper bits ... The 68000 series migrated to
>32-bit addresses and couldn't execute older software.

IBM programmers did that on the 360s and in the late 50's,
the Electrodata Datatron systems recommended using unused operand
fields in the instructions as temporary storage.

Joe Monk

unread,
Jul 12, 2021, 1:30:46 PMJul 12
to

> IBM programmers did that on the 360s and in the late 50's,
> the Electrodata Datatron systems recommended using unused operand
> fields in the instructions as temporary storage.

Yes, and it is a major irritation for Paul, which I think is funny as shit.

He can't create 32-bit programs on his PDOS/3X0 because we use the top bit (bit 0 in a 32-bit address) as a flag to indicate the end of a parameter list, a technique which is still in use today and was first started on the IBM 360 series. Noone in the IBM world has a problem with 31-bit programs ...

Joe

muta...@gmail.com

unread,
Jul 12, 2021, 2:56:54 PMJul 12
to
On Tuesday, July 13, 2021 at 3:30:46 AM UTC+10, Joe Monk wrote:

> > IBM programmers did that on the 360s and in the late 50's,
> > the Electrodata Datatron systems recommended using unused operand
> > fields in the instructions as temporary storage.

> Yes, and it is a major irritation for Paul, which I think is funny as shit.
>
> He can't create 32-bit programs on his PDOS/3X0 because we use
> the top bit (bit 0 in a 32-bit address) as a flag to indicate the end
> of a parameter list,

That is not correct. I create 32-bit programs just fine.

If other people's crappy programs don't work, that's
their problem. RPF works after it was cleaned up.
Everything based on PDPCLIB works after it too was
cleaned up.

> a technique which is still in use today and
> was first started on the IBM 360 series. Noone in the IBM world
> has a problem with 31-bit programs ...

That omniscience in action again.

BFN. Paul.

muta...@gmail.com

unread,
Jul 12, 2021, 2:59:18 PMJul 12
to
On Tuesday, July 13, 2021 at 3:14:37 AM UTC+10, Scott Lurndal wrote:

> >> The more I look at the 8086, the more I am happy
> >> that segmentation was the correct technical
> >> solution to cope with machines that still had a
> >> 16-bit processor and registers, but had more than
> >> 64k memory available to them. I just would have
> >> made the segment shift flexible instead of telling
> >> everyone that "4" was being set in stone.
> >
> >They would've been wiser to split a 32-bit address across two registers
> >instead of using a 4-bit shift and add. That would've allowed for an
> >easier transition to 32-bit.

[to Rod]

Care to elaborate on that?

printf("hello, world\n");

transitioned from 16-bit to 32-bit perfectly fine.

So what specifically is wrong with the 8086?

> Even in 1978, when the 8086 was launched, segementation was recognized
> as a poor choice for memory management.

Well I don't recognize that even in 2021. What am I missing?

Thanks. Paul.

Joe Monk

unread,
Jul 12, 2021, 4:21:14 PMJul 12
to

> > Even in 1978, when the 8086 was launched, segementation was recognized
> > as a poor choice for memory management.
> Well I don't recognize that even in 2021. What am I missing?

From: https://retrocomputing.stackexchange.com/questions/6979/why-didnt-the-8086-use-linear-addressing/6989

Another reason that we have clear evidence for: Intel's previous chip, the 8080, supported a 16-bit, 64KiB, memory space. The dominant operating system for it was CP/M. Intel and Microsoft both made a serious effort to make the new environment as source-compatible with CP/M code as possible.

I will give examples from MS-DOS 1.0, because that was the most important and best-documented OS that took advantage of this feature. Back when the ISA was being developed, IBM had not yet chosen the 8088 for its Personal Computer Model 5150, there was a large library of 8-bit CP/M software, and memory was even more expensive, all the considerations I am about to mention were even more crucial.

The segmentation scheme allowed an OS for the 8088/8086 to emulate an 8080 running CP/M with minimal hardware resources. Every MS-DOS program was initialized with a Program Segment Prefix, which just like it says on the tin, was loaded at the start of the program segment. This was designed to emulate the Zero Page of CP/M. In particular, the 8080 instruction to make a system call in CP/M was CALL 5. If you use that instruction in a MS-DOS program, it will still work. The Program Segment Prefix will be loaded into CS, and CS:0005h contains a jump to the system-call handler of MS-DOS.

Segmentation effectively gave every legacy program its own 16-bit memory space, allowing it to use 16-bit pointers as it always had. This both saved memory and saved 8-bit code from needing to be extensively rewritten. (Recall that most software today runs on 64-bit CPUs, but ships as 32-bit programs because smaller pointers are more efficient; this was even more crucial on an original IBM PC model 5150.) A .COM program was based on the executable format of CP/M, and got by default a single segment for code, data and stack, so a program ported from CP/M could treat the 8086 as a weird 8080 where it had the whole 64KiB of memory to itself and the registers had different names. MS-DOS 2.0 let programs start with separate segments for their code, stack, data and extra data, still using 16-bit pointers and offsets. Of course, a program aware of the full 20-bit address space could request more memory from the OS. In MS-DOS, it could request memory in 16-byte "paragraphs" (bigger than a word, smaller than a page) and would get them in a new relocatable segment, whose exact value it did not need to care about or waste a precious general-purpose register to store. (Unlike shared libraries for the x86 and x86_64 today!)

But why not shift segment registers 16 bits to the left, instead of four, for even less complexity, and let programs use only the lower-order 8 or 16 bits of a 32-bit address space, for offsets within the current page of memory? The apparent advantage is that it allowed segments to be aligned on any 16-byte boundary, instead of a 65,536-byte boundary. Any program back then needed to use a lot less than 64KiB of memory, and exceptionally few computers even shipped with the 256KiB that the CS, DS, ES and SS registers could address. The OS, the program in the foreground and every program to Terminate-and-Stay-Resident could not all have gotten their own 16-bit address spaces, much less separate ones for their code, data, and stacks, if every segment had needed to be on a 64KiB boundary. But, with the memory model Intel used, programs could use 16-bit pointers with much smaller memory blocks.

Joe

muta...@gmail.com

unread,
Jul 12, 2021, 5:17:52 PMJul 12
to
On Tuesday, July 13, 2021 at 6:21:14 AM UTC+10, Joe Monk wrote:

> > > Even in 1978, when the 8086 was launched, segementation was recognized
> > > as a poor choice for memory management.

> > Well I don't recognize that even in 2021. What am I missing?

> But, with the memory model Intel used, programs could use 16-bit pointers with much smaller memory blocks.

Everything you quoted showed that the 8086 was perfect.

If there is something specifically wrong with the silicon
itself, please explain.

I'm not interested in the fact that Gates was a jackass.

BFN. Paul.

Rod Pemberton

unread,
Jul 12, 2021, 6:06:34 PMJul 12
to
On Mon, 12 Jul 2021 11:59:17 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> On Tuesday, July 13, 2021 at 3:14:37 AM UTC+10, Scott Lurndal wrote:

> > >> The more I look at the 8086, the more I am happy
> > >> that segmentation was the correct technical
> > >> solution to cope with machines that still had a
> > >> 16-bit processor and registers, but had more than
> > >> 64k memory available to them. I just would have
> > >> made the segment shift flexible instead of telling
> > >> everyone that "4" was being set in stone.
> > >
> > >They would've been wiser to split a 32-bit address across two
> > >registers instead of using a 4-bit shift and add. That would've
> > >allowed for an easier transition to 32-bit.
>
> [to Rod]
>
> Care to elaborate on that?
>

Instead of different x86 addressing modes for 16-bit and 32-bit
instructions, the instructions could've been the same. 32-bit x86
instructions are clean and orthogonal. 16-bit x86 addressing modes are
a complete mess.

muta...@gmail.com

unread,
Jul 12, 2021, 6:55:49 PMJul 12
to
On Tuesday, July 13, 2021 at 8:06:34 AM UTC+10, Rod Pemberton wrote:

> > > >They would've been wiser to split a 32-bit address across two
> > > >registers instead of using a 4-bit shift and add. That would've
> > > >allowed for an easier transition to 32-bit.
> >
> > [to Rod]
> >
> > Care to elaborate on that?
> >
> Instead of different x86 addressing modes for 16-bit and 32-bit
> instructions, the instructions could've been the same. 32-bit x86
> instructions are clean and orthogonal. 16-bit x86 addressing modes are
> a complete mess.

I'm not 100% sure I understand you, but I want a solution
that is constrained by the number of registers, including
segment registers, that were available in the 8086, plus
the need to support existing 16-bit applications in a memory
constrained environment.

If there was a lack of foresight, that's fine, but you can't
just say "well they should have used the full x64
instruction set".

A subset of x64 that supports 16-bit applications in a
memory-constrained (but more than 64k) environment
is fine.

What is that subset?

Thanks. Paul.

muta...@gmail.com

unread,
Jul 12, 2021, 7:30:19 PMJul 12
to
On Tuesday, July 13, 2021 at 8:55:49 AM UTC+10, muta...@gmail.com wrote:

> I'm not 100% sure I understand you, but I want a solution
> that is constrained by the number of registers, including
> segment registers, that were available in the 8086, plus
> the need to support existing 16-bit applications in a memory
> constrained environment.

Another constraint - considering future generations is
great, and should be done, but they are not infinitely
more important than the present, and they are the ones
who benefit from technological improvement, so have
a less constrained environment.

So don't impact performance/cost of the present by more
than say 10%.

BFN. Paul.

Alexei A. Frounze

unread,
Jul 12, 2021, 10:23:13 PMJul 12
to
On Monday, July 12, 2021 at 8:27:31 AM UTC-7, Rod Pemberton wrote:
> If you want to read about some of the problems transitioning to 32-bit,
> see the 68000 micro-procesor which had 24-bit addresses. Programmers
> found uses for those upper bits ... The 68000 series migrated to
> 32-bit addresses and couldn't execute older software.

They could've required bit 23 of the address to zero/sign-extend to
bits 24 through 31 in the original design to discourage tricks that hamper
compatibility. Like the "canonical addresses" on x86-64.

Or if there was page translation on the 68000 (looks like it was on the 68010),
they could've probably mapped addresses of 16M and greater onto the same
range as the ones below 16M, that is, having multiple aliases to the same RAM.

Alex

Alexei A. Frounze

unread,
Jul 12, 2021, 10:33:16 PMJul 12
to
On Monday, July 12, 2021 at 3:06:34 PM UTC-7, Rod Pemberton wrote:
> Instead of different x86 addressing modes for 16-bit and 32-bit
> instructions, the instructions could've been the same. 32-bit x86
> instructions are clean and orthogonal. 16-bit x86 addressing modes are
> a complete mess.

I guess, they tried to balance expressiveness/features and size/speed,
hence the non-orthogonal design.
At the same time, while I agree that it's nasty, it's probably not too bad.
I've been able to make a greedy local register allocator for the 8086 and
its output seems fairly decent. See https://github.com/alexfru/regal86 .
[Of course, handcoded optimizations could beat the compiler in tough situations].

Alex
Reply all
Reply to author
Forward
0 new messages