segmentation

[muta...@gmail.com]

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]

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]

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]

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]

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]

> 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]

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]

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]

> > 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]

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]

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]

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]

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]

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]

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

[muta...@gmail.com]

On Tuesday, July 13, 2021 at 1:14:37 AM UTC+8, Scott Lurndal wrote:
> 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).

Would it have been possible within the limits
of late 70s/early 80s technology to have an
Instruction or jumper to switch between 4 and 5 bit
segment shifts at a minimum?

Actually, just being able to determine
whether the current cpu is 4 or 5 bits
would be good enough.

And that could even be hardcoded in software
I think. If necessary. What options were open?

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Tuesday, July 13, 2021 at 1:14:37 AM UTC+8, Scott Lurndal wrote:
>> 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).
>
>
>Would it have been possible within the limits
>of late 70s/early 80s technology to have an
>Instruction or jumper to switch between 4 and 5 bit
>segment shifts at a minimum?

Anything is possible. But the design, engineering and
testing of such a feature would add cost, for no gain.

[muta...@gmail.com]

Not everything is possible. Intel couldn't
have fabricated an x64 in 1978.

So can you tell me what is possible and what
the extra cost is for each option. Are we talking 1%, 10%, 100% extra?

One option would be to have an 8086
exactly as is, and a new processor, 8086-5,
which is exactly the same except 5 bit shifts.

The os software needs to know which of the
2 processors it is running on.

If necessary, 2 versions of the os could be
produced, but that's pretty crappy.
Although it could be done in a way that just
one byte needs to be zapped with either 4 or 5.

Another option would be to have a modified
8086 that has an instruction to set the desired
shift, with an initial value of 4.

Another option would be an additional
instruction to let you know if this processor is a
fixed 4 or 5 bit shift.

Another option would be a bios call to
determine the unchanging shift value of
the current processor.

What would you recommend within the
constraints of late 70s hardware and my
desire for a flexible shift value, not
necessarily immediately, but with a new
8086-5+ to be released in the mid 80s.

I'm looking to address 2 MB. When
could that much memory be bolted on?

[Scott Lurndal]

Sure they could have. It would have cost a fortune, and
required many thousands of SSI chips. But it could be done.

>
>So can you tell me what is possible and what
>the extra cost is for each option. Are we talking 1%, 10%, 100% extra?

Hard to say. The transistor budget for the process node they were using
was pretty small; Who knows what adding a couple of flops and the
associated wiring would have cost. Note also at the time, they were
still laying out the circuits on big drafting tables, and there were no
fancy EDA tools. They ran simulations on very large, very expensive
mainframes. A minor change could easily cascade into something major.

They'd have to have a large customer demand for the feature to even
consider it.

>
>One option would be to have an 8086
>exactly as is, and a new processor, 8086-5,
>which is exactly the same except 5 bit shifts.

That's still a costly proposition, see above. And they'd have
to expect to make their investment back, plus profit.

>
>
>What would you recommend within the
>constraints of late 70s hardware and my
>desire for a flexible shift value, not
>necessarily immediately, but with a new
>8086-5+ to be released in the mid 80s.

I'd recommend you look at the Motorola 68000.

[muta...@gmail.com]

No, that's not what I'm after.

Ok, what if the 5 bit segment shift option was
to be added to the 80286 or 80386 instead?
Would that be a minor addition?

And maybe for the 8086 have an instruction that just
loads the number 4 into ax? Would that be a minor cost?

I understand it's not something you personally want or think
is sensible. It is something that I want and think is
sensible, but you are the one with the required
technical knowledge to answer my question.

Another option would be no change at all to the 8086
and you instead detect if you have an 80286 and if so, you know
the flexible shift value instruction is available. But that
seems clumsy.

And should there be an instruction to set the shift value
dynamically? And on the 8086 that would be a noop.

So the procedure is to set what value you want, but then
retrieve the current shift value, which may or may
not have changed.

And you know what? I think regardless of how the hardware does
or doesn't do it, this should be hidden in a bios call.

If the bios has to have logic to detect if it is an
80286+, it doesn't matter if that is clumsy.

And it doesn't matter if it is something done by the user
in the bios setup.

And Bochs could have an updated bios even if normal
machines don't.

Does that sound reasonable for my, not your, goals?

And where specifically should the bios call
be put? Interrupt number and procedure for
setting, or at least getting, the shift value.

I think there would never be a need to set the
shift value dynamically by the os.

Maybe if someone has a need for that it could
be added later.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Tuesday, August 30, 2022 at 7:19:44 AM UTC+8, Scott Lurndal wrote:

>> >What would you recommend within the
>> >constraints of late 70s hardware and my
>> >desire for a flexible shift value, not
>> >necessarily immediately, but with a new
>> >8086-5+ to be released in the mid 80s.
>> I'd recommend you look at the Motorola 68000.
>
>No, that's not what I'm after.
>
>Ok, what if the 5 bit segment shift option was
>to be added to the 80286 or 80386 instead?
>Would that be a minor addition?

There is no such thing as a minor addition (no pun intended)
when adding features to a processor chip.

>
>And maybe for the 8086 have an instruction that just
>loads the number 4 into ax? Would that be a minor cost?

The 8086 already has an instruction that loads the number 4
into AX (MOV AX,4 / mov $4,%ax).

There is no such thing as a minor change when designing
and implementing a CPU. Consider the effect on the
instruction decoder alone; if it uses a VLIW-style
implemention, a new ROM will need to be developed and
tested for the entire supported feature set (instructions
and corresponding semantics), if it uses straight logic,
the entire logic tree needs to be redesigned, laid out
(by pen and ink in those days), and reimplemented.

Like I noted earlier, anything is possible given enough
time and money.

[anti...@math.uni.wroc.pl]

You would need 17 bit multiplexers to shift bits. Plus on
flip-flop to remember state + buffers to deliver signal to multiple
points. Plus decoding logic for extra instructions to read/set
this extra bit. In modern CMOS multiplexers are quite cheap, you
can do 1-bit multiplexer with 4 transistors. But in NMOS you
probably need active logic for this, which would be
of order 20-30 transistors. Flip-flop should be below 20
transistors. For buffers probably 70 transistors would be
enough (incuding in it buffer to data bus). To decode pair
of similarly encoded instructions in principle 7 AND gates
and OR gate with 7 inputs is enough, that is about 100
transistors. But you need to glue this to existing logic
which may require buffers, multiplexers and extra gates.
There may be some simplification if you are able to
hook into right place in existing logic. Or there may
be complications.

But overall what you want should be doable below 1000
transistors. 8086 was reported to have 27000 transitors,
so probably below 5%.

Note that this 4-5 shift bit feature would be essentially
useless because 8086 has 20 bit address bus so with 5 bit
shift you would be forced to drop highest bit of resulting
address. Adding extra address line would be quite problematic,
8086 already is doing tricks to fit existing signals into
available pins. Going to bigger package probably would
have moderate impact on cost of 8086 say something like
20-30%. But it would mean more larger, expensive PCB
for every user. And that could essentially kill 8086.

For 286 your 5-bit shift technically would be quite cheap.
But politically it would be very hard, they wanted everybody
to use protected mode and 5-bit shift would go in different
direction. So you would need a strong hit squad and keep
guns to heads of several key Intel people during design
process to make it happen.

There were many alternative that Intel could take.
One possiblity was 16-bit "segment shift", this was
done on Z8000, would give cheaper, but less useful
processor. Another possibility would be to extend
registers to 20-bit. Assuming that normal data
intructions would be limited to 16-bit and that
extra 20-bit operations would be done as pair of
16-bit operation followed by 4-bit operation,
that would be quite cheap, probably giving
some saving on execution side: no need for
adder adding segment to base address, 8 extra
4-bit registers instead of 4 16-bit segment
registers. Decoding probably would have similar
complexity as real 8086. But in such version it
would be natural to have 32-bit return address on
the stack, which would be more expensive than
16-bit return address and would probably destroy
compatiblity with 8080.

Let me remark that 8086 could be used in two basic
configuration: minimal one and maximal one. IIRC
in "minimal" configuration 8086 is limited to 16
address lines (but there is less external chips).
So 8086 had to compete with existing 8 bit CPU-s.
And 8088 using 8-bit data bus was intended as
better replacement for 8 bit CPU-s.

Polish K-202 from around 1972-1973 was 16-bit mini which
boasted with ability to connect 16 M of memory. This
was done with simple trick: there was 8-bit latch
providing 8 high address bits. CPU could reload
this latch with new value and in this way switch to
different 64-kB "page". Simple, cheap but of
limited value. In late period 8-bit micros had
"paging unit": essentially it was small RAM
which took say 4 high address bits and provided
say 12-bits as replacement. So you got 16 M
address space divided ino 4 kB pages. At each
time 16 arbitrarily chosen pages were available
to normal 16-bit addressing. Appropriate RAM
chips were available in 1974 and probably few
years earlier. So ability to address largish
memory was certainly available in 1974.
But it would be silly to connect memory worth
millions of dollars to cheap and slow computer,
spending part of money on better computer
(and possibly hard disc to swap) would give you
much more compute power overall. 2M memory
in resonably priced computer was possible
around 1985, and at that time you got Amiga,
Atari ST and 386.

--
Waldek Hebisch

[muta...@gmail.com]

I don't know if you genuinely don't understand my
proposal, but it is only on the 8086 that the
instruction would simply put 4 into ax or ah or al.

On other processors, not necessarily built by
Intel, the instruction would return anything from
4 to 16.

[Scott Lurndal]

Ok. So you want opcode 0F A2. Just wait a couple
generations. All the above concerns still apply
when considering adding it to 8086. Other posts
have noted an approximate transistor cost (and 5%
is a large cost for a feature that doesn't really
work without extending the width of the address
bus internally).


https://c9x.me/x86/html/file_module_x86_id_45.html

[muta...@gmail.com]

Ok, thanks for that analysis.

Don't worry about political constraints, I'm on
first name terms with Jens.

I'm interested in hardware, technology and
financial constraints.

Based on what you have said, 2 MB on the 8086
is not a good idea.

However, what about preparation for the future
by having an instruction that checks the shift value
in use, and simply returning 4? Or is a
processor instruction inappropriate?

However, when msdos 2.0 came out,
in 1983, the 80286 existed, and 2 MB of
memory was affordable if you really had your
heart set on it. I'm not sure the motherboards existed though.

What I am trying to do is run msdos 2.0 on
the 8086 with limited memory, and pdos 86 on
a 80286+ with 2 MB memory.

And then write applications that will run
on either system, binary compatible.

That seems to be both possible and neatly
designed. I don't think hardcoding the number 4
in 27 billion different places is superior.

Yes, the 80386 will become affordable
eventually, but I don't think it is correct to
rely on that. It could take 5 decades.

So, what is good design, be it bios
call, instruction, linker?

[muta...@gmail.com]

Thanks for the reference.

5% was the cost of adding a working flexible
shift, not an instruction that simply returns 4,
or your latest proposal to implement cpuid.

Do you think a limited cpuid is practical for the 8086
or should it only be implemented starting with the
80286?

That's 2, not 3.

[Scott Lurndal]

Note to anti... he's referring to a CPUID instruction analogue.

Note to muta... Why 4? A single bit is sufficient, and easily
allows future extension to describe additonal optional features.

[muta...@gmail.com]

When 8 MB becomes affordable, but
the 80386 is still not affordable, the
shift will be 6, not 5.

This continues up until you have 4 GB of
memory. It is highly unlikely we will ever reach
4 GB of memory, I mean, 640 MB should be
enough for everyone, but I believe correct
mathematical design calls for the
theoretical possibility of having 4 GB of
memory.

This is the conversation I expect in the Intel
design room in 197x.

I also expect them to conclude that they
will make minimal effort for the 8086 itself,
but they have a clear pathway for whatever
the hell comes after the 8086.

I expect the conversation to take an hour or two
as they think through the implications for
the linker etc to confirm that 4 is not
a hard limit, and the software jackasses
have all the required tools available if they
bother to think it through.

And even if they never make actual hardware
that can do 5 or more bit shifts, an emulator
may be written which can.

So the binaries will remain valid for
centuries to come.

There is a hard limit of 16 bit shifts to
give 4 GB of memory, but that is a
reasonable limit.

4 bits and 1 MB is totally unreasonable as
a hard limit to be hardcoded in software.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Wednesday, August 31, 2022 at 6:44:56 AM UTC+8, Scott Lurndal wrote:
> > "muta...@gmail.com" <muta...@gmail.com> writes:
> > >On Wednesday, August 31, 2022 at 2:39:56 AM UTC+8, anti...@math.uni.wroc.pl wrote:
> >
> > >However, what about preparation for the future
> > >by having an instruction that checks the shift value
> > >in use, and simply returning 4? Or is a
> > >processor instruction inappropriate?
> > Note to anti... he's referring to a CPUID instruction analogue.
> >
> > Note to muta... Why 4? A single bit is sufficient, and easily
> > allows future extension to describe additonal optional features.
>
> When 8 MB becomes affordable, but
> the 80386 is still not affordable, the
> shift will be 6, not 5.
>
> This continues up until you have 4 GB of
> memory. It is highly unlikely we will ever reach
> 4 GB of memory, I mean, 640 MB should be
> enough for everyone, but I believe correct
> mathematical design calls for the
> theoretical possibility of having 4 GB of
> memory.

You clearly leave in alternative universe. In alternative
universe normal logic, physics or market laws does
not work, so arguments from real world are invalid.
Still, it makes sense to say a bit about history.

> This is the conversation I expect in the Intel
> design room in 197x.

Well, if you look at electronics publications you would
find that already in early seventies it was predicted
that before 1990 it will be possible to put 360 class
processor on a single chip. So I expect Intel
engineers to look at feasiblity of providing 32-bit
processor. And they did provide one in 1981,
namely 432. AFAIK in 1982, when 286 was released
they seriously worked on 386.

Intel folks looked at many ideas, so it is possible
(evan likely) that idea of variable segment shift was
considered, but it simply lost to better ideas.

> I also expect them to conclude that they
> will make minimal effort for the 8086 itself,
> but they have a clear pathway for whatever
> the hell comes after the 8086.
>
> I expect the conversation to take an hour or two
> as they think through the implications for
> the linker etc to confirm that 4 is not
> a hard limit, and the software jackasses
> have all the required tools available if they
> bother to think it through.
>
> And even if they never make actual hardware
> that can do 5 or more bit shifts, an emulator
> may be written which can.

You still do not want to acknowlege that 286 was
superior design compared to variable segment
shift. The only drawback of 286 was limitation
to 16M of memory, but Intel understood that
with such amount of memory real world users
want 32-bit processor. So they provided one,
after failed 432 they deliverd 386. And if they
failed to deliver, there was 68000 and later
several RISC processors. Without 386 or similar
processor PC era would be history now. And 16-bit
PC era _is_ history.

BTW: Intel got really serious about binary compatibility
with 386. With 286 "well written" programs are supposed
to run unchanged in protected mode, but other had to
be fixed first. With 8086 thay provided tool to translate
8080 assembly into 8086 assembly. But instructions encodings
were quite different, so this did not help if you had only
8080 binaries (OK, you had to spend work disassembling
and then you could use the tool). And that is justified
by their market: many microprocessors run single program,
the processor was just one part of a device like printer,
monitor, disc drive etc. Since thare was single program
manufactur could spend some effort to adapt it to new
processor and what Intel provided was adequate.

--
Waldek Hebisch

[muta...@gmail.com]

I think you misunderstood me. I didn't make any
comment saying variable shifts were superior to
the 80286.

My only comment was that people writing 8086 software,
including operating systems, shouldn't be hardcoding the number 4,
just because the first processor, just about to be
manufactured, happened to use 4 as the shift value.

There are multiple ways to avoid hardcoding the number 4,
and one of those ways would be an instruction that returned the number 4
on the 8086, but the 8086 documentation said it is the shift bits,
and not guaranteed to be 4 in future
processors.

If this had been done, then a future
processor, and indeed it's still not too late,
AMD could do this next year on their x64
processors, in rm16, could suddenly switch to
5 bit shifts, or anything else up to 16.

And then all correctly written 8086 software,
including the os, would suddenly have more memory
available.

What's not to like about that?

Yes, obviously if you recompile the source,
and the source is clean, allowing 32 bit
everything, that will work too.

But if all you have is a correct 8086
binary, then that's fine too, most memory
constraints will be lifted thanks to
future development of processors and
cheaper memory.

And that is the paradigm I want my
8086 software to adhere to.

And yes, I'm still developing 8086
apps and an os.

And yes, I'm hoping AMD will make that change.
Or even Intel.

Even Bochs would be something.

If you now understand what I am trying to
do, then I would like specific recommendations
for what should have been done at the time
the 8086 was designed, or failing that,
what should have been done at the time the
80286 was designed, or failing that,
what change I should make in Bochs rm16
and bios calls.

Another thing - with the bios being in ROM,
the image will need to have a predefined
segment shift.

However, if I create my own bootx64.efi,
and install my own int 13 etc to UEFI
code, I think I can have a bios that works
with whatever the segment shift happens to be.

[muta...@gmail.com]

One more thing I need.

I want Intel to document that address wraparound at 1 MB is
not guaranteed, and implementors should provide a bios
call which switches on wraparound.

The default is undefined status.

Actually, I guess I can live without that.

But with the benefit of hindsight, I assume
that would be proper design?

[muta...@gmail.com]

No, default status is no wraparound, but some
environments may wrap around anyway due to the fact
that there are 20 or fewer address lines.

[wolfgang kern]

On 01/09/2022 14:48, muta...@gmail.com wrote:

[...]

> No, default status is no wraparound, but some
> environments may wrap around anyway due to the fact
> that there are 20 or fewer address lines.

The KEY to wrap around at 1MB once was the A20 gate,
it's now just an historical thing found only in museums.
PCs don't even have an A20 gate anymore (==always ON).

the HMA (0010_0000 aka FFFF:0010..) was very often used
by DOS and friends, so they needed A20 ON.

easy to make it wrap at 1MB with segment limits.
but it will wrap only if the access is aligned while
crossing the boundary with a multi-byte instruction
end up in a Seg-Fault or with an GP-error if PM.
__
wolfgang

[muta...@gmail.com]

Sure. What I'm looking for is a set of rules
to follow, with the benefit of hindsight.

From memory, the PSP used when a .com file
is loaded, makes use of address wrap.

Rather than just say that .com files should
not be supported, given that someone
actually wants this feature, the rule simply
needs to say that you need to do a deliberate
bios call to switch this feature on.

If you don't, your code will work now, but when
the 80286 comes out with more than 20
address lines, your code will break.

I don't care if code breaks, I just want
sensible rules to follow.

If msdos 2.0 breaks because they didn't
do the required bios call, I don't care. I will just
email bill asking for a bug fix.

If he doesn't reply to my email, I don't
care. I will use pdos/86 instead.

And I think when I was looking at the PSP
I saw that an alternative solution would be
to store a little bit of code at the 1 MB location.

If existing code is using the beginning of
the HMA, then my response is to change
your code.

I am not trying to run every bit of
unsupported binary code in existence.

I am trying to run supported software with
source code where the vendor agrees
with the desire to clean up rm16.

Note that the above probably restricts the
number of vendors to 1, but I don't care about
that either.

It's a theoretical problem.

It isn't just the 8086, it's any
16:16 processor with an initial shift
of 4 bits, with intention to be flexible
in the future regarding shift bits.

Shift bits could be anything from 0 to 16,
because there is a mathematical possibility.
Actually, I think 0 should be ruled out as a
logical number in segmentation.

Basically this is a theoretical problem in
computer science I would like to solve or explore.

Actually constructing a time machine and hiring
ninjas to assassinate certain key engineers
and managers at Intel is beyond scope.
For now.

[wolfgang kern]

On 02/09/2022 19:20, muta...@gmail.com wrote:
> On Friday, September 2, 2022 at 6:53:49 PM UTC+8, wolfgang kern wrote:

>> [...]
>>> No, default status is no wraparound, but some
>>> environments may wrap around anyway due to the fact
>>> that there are 20 or fewer address lines.
>> The KEY to wrap around at 1MB once was the A20 gate,
>> it's now just an historical thing found only in museums.
>> PCs don't even have an A20 gate anymore (==always ON).
>>
>> the HMA (0010_0000 aka FFFF:0010..) was very often used
>> by DOS and friends, so they needed A20 ON.
>>
>> easy to make it wrap at 1MB with segment limits.
>> but it will wrap only if the access is aligned while
>> crossing the boundary with a multi-byte instruction
>> end up in a Seg-Fault or with an GP-error if PM.

> Sure. What I'm looking for is a set of rules
> to follow, with the benefit of hindsight.

> From memory, the PSP used when a .com file
> is loaded, makes use of address wrap.

I cannot confirm your assumption above,
.com are organized at 0100 so the PSP is at 0000.
therefore a .com-file is size limited to 63.75K.

Rules ? my rules are according to given hardware.
I'd just recommend to always avoid address wrap [A20 ON].

the inherent backwards addressing uses overflow to make
an unsigned displacement look as if signed [isn't wrap].

for speed reasons my initial ESP=0, it could under-run]
old DOS used a misaligned SP (ffff instead 0) to force
a segment fault on stack under-run [but made all slow].

as you seem to work on virtual machines you can define
whatsoever rules you like :)
You cannot alter any features of existing REAL hardware.

AFAIK x86 is the only CPU family with address Shift-Add. Others
use either banks or two [w/o shift] registers for >64K.
__
wolfgang

[muta...@gmail.com]

Although we can't change existing hardware, we can
start by agreeing that Intel engineers missed
some things that only came to light when
pointed out by an obnoxious Australian, instead of
dismissing everything he says in favor of
professional infallible Americans.

After establishing that apparent truth we can
discuss what options exist to compensate for American engineering failures.

This includes the option of altering or
replacing historical software.

Here's the PSP thing:

https://groups.google.com/g/comp.os.msdos.programmer/c/ZvWGKqT5Fvc/m/skFPO1H3EAAJ

[wolfgang kern]

On 04/09/2022 06:32, muta...@gmail.com wrote:
...

> Although we can't change existing hardware, we can
> start by agreeing that Intel engineers missed
> some things that only came to light when
> pointed out by an obnoxious Australian, instead of
> dismissing everything he says in favor of
> professional infallible Americans.

in terms of costs and performance it was an absolute correct
solution at the time back then. [COP4..8080,8085,8086]
Improvements came with time anyway, we cannot alter history.

> After establishing that apparent truth we can
> discuss what options exist to compensate for American engineering failures.

> This includes the option of altering or
> replacing historical software.

you can only replace it. no way to modify old CPUs.

> Here's the PSP thing:
>
> https://groups.google.com/g/comp.os.msdos.programmer/c/ZvWGKqT5Fvc/m/skFPO1H3EAAJ

[quote]
> So:
>
> 05h = 9A
> 06/07 = FEF0
> 08h = 1D
> 09h = F0
>
> So the 06/07 "segment size" of nearly 64k is basically
> just maxing out the memory available to the .com
> program.
>
> But how does 9A + 1D + F0 translate into a call to 00C0?

you have this all wrong :):)
9A F0 FE 1D F0 is an absolute CALL FAR into a BIOS location
FEFO become IP and F01D became CS (could be a branch to 00C0)
__
wolfgang

[muta...@gmail.com]

It was not absolutely correct, it was almost
correct. They just needed to document some things
to future proof it or add some minimal
enhancements.

You can argue that the things I have
identified weren't known to computer
science at the time and we're only
added to science in 2022 so it is not
their fault.

Noone had done segmentation before and it
would take decades of science still to
work through the repercussions.

And yes, we can't change the physical
processor nor history, but we can make
use of 40 years of additional science to
see what could have been done differently.
slight changes, not complete replacement.

Alternatively we can stick out fingers in
our ears and deny that it is possible for
someone from the southern hemisphere to
improve the design of a group of northern
hemispherans.

Which do you prefer?

And you CAN change historical software,
either by zapping the binary or
recompiling the source code.

The source code to msdos 2.0
has been made available.

Microsoft likely still has all the other source
available too.

[Scott Lurndal]

"muta...@gmail.com" <muta...@gmail.com> writes:
>On Sunday, September 4, 2022 at 9:25:34 PM UTC+8, wolfgang kern wrote:
>> On 04/09/2022 06:32, muta...@gmail.com wrote:

>Noone had done segmentation before and it
>would take decades of science still to
>work through the repercussions.

Several very successful systems that predate the
8086 by a full decade used segmentation; examples include the PDP-11,
the B6500 et alia.

[muta...@gmail.com]

They presumably didn't do 4 bit shifts or similar
so didn't hit the a20 issue nor the flexible shift issue.

The a20 is probably because of cp/m PSP though,
not segment shift.

[s_dub...@yahoo.com]

~~~

Gosh, istm you have these concepts jumbled up.

Sorry for the review but..
The 8080 cpu has 16 address lines A0..A15, we show this as a hexidecimal word..

Which ranges, 0000h..FFFFh, with each address addressing an 8-bits byte.
This amounts to 65,536 bytes (64k) addressable, for the 8080 cpu.
The Code, Data, and Stack concepts are intermixed in the address range.
Segment logic in not supported in the 8080 hardware.

The address lines are binary, where each line is conceptually a bit with the
value of either a 0 (clear) or 1 (set).
The address lines together (16 lines are 16 bits) indicate an address value.
The address value is shown _in hex_ with 4 'nibbles' nnnnh, with 2 'nibbles'
forming a 'byte' nnh of 8 bits. Conceptually, a nibble (nh) is 4 bits.
Yet note that the smallest directly addressable element is a BYTE.
Nibbles and bits are indirectly accessable thru processor instructions of
shift, rotate, logic masking etc in the context of a directly addressed byte or
word. IOW you can make a pointer to a byte or word directly but not a pointer
to a bit directly. You can make a pointer to a bit in a bit field indirectly
as a side effect of making a pointer to a byte or word (with extra processing).

The binary nature of bit values, set (1) or clear (0) lends itself to 'power of
2' math in the cpu venue. Consequently, a value in the accumulator shifted
left is a 'power of two' multiply. A value shifted right is a 'power of 2'
divide.

Lets consider a nibble, whose value is 1, is in the low order position of a byte in the accumulater, 01h.
We decide we want to place that nibble in the high order position of the byte
in the accumulater, as 10h, the processor command to left-shift-by-4 gives our
desired result. An 1x2**4 = 16, reflected in hexadecimal as 10h.

Note that the 8080 does not have multiply and divide instructions.
Those functions were performed in software using the bit shift, logic, compare,
and other primitives. Still, trig and floating-point libraries were developed
for the 8080. You know, when programmers were PROGRAMMERS!

CP/M, which should be called CP/M-80 to be clear, is an 8080 OS.
86-DOS was the precursor to PC-DOS & MS-DOS.
86-DOS took the logic of cpm-80 and tranfigured it for the 8086/88 cpu. Also
it adopted the fat file system.
CP/M-86 was a new OS that adopted the filesystem of cp/m-80 v2.2 and the same
BDOS function numbers plus additions for the 8086, notably, setting the 'base'
ie. segment value of a DMA buffer. It adopted a 'loader linkage record'
- my terminology - which told the loader how to set the segments for an
executable .CMD file.

Segmentation was thought to be helpful in program reliability by computer scientists because the separation of code from data could lesson bugs of
corruption of code or data or both.

The 8086 has a linear addressing range of 00000h..FFFFFh.
Five nibbles = 20 address lines which are named A0..A19 inclusive.
An increment on an address value of FFFFFh rolls-over to address 00000h.
This is effectively a circular buffer structure but pertaining to code.

The A20 'thing' was not a 'thing' until subsequent cpu's expanded the address
lines above the 8086 range, that is A20++.

The 'thing' was that 86-dos, pc-dos, & msdos depended on the 8086 address
roll-over to implement cp/m-80 CALL 0005h operation. As I recall, I saw
'call 5' was in one of the utilities for 86-DOS src yet CALL 5 is supported in
CMD.EXE .COM programs, up thru XP at least.

So, no roll-over is bad. So the A20 was made to be toggled either normal or
always clear until the controlling flag is changed. This was done by the OEM
so as to not break those dos's.

As to 8086 segmentation.. we have a linear address range of 00000h..FFFFFh.
An offset range for code and data, stack and ES of 0000h..FFFFh, 16 bits MAX.
A common data structure is an array. Consider MyArray[0h..Fh].
MyArray is a standin for a segment number, and an offset range of 0000h..000Fh.
In this case, we are allowed 64k of array structures of size 16 bytes.

So, treating 'segment' as a 'base' and the offset as an 'index' makes some
sense. So the 'base' is the high order element and the 'index' is the low
order element in any case. So it make sense to apportion the address range
as:
base as BBBB'X and
index as X'IIII
where X means 'not used'
Some Combination of the two gives
BBBB-h
+ -IIIIh
= CCCCIh So from the combination of the two, they cover our addressing range.

Obviously, in the real world; combinations, compaction, alignments, etc,
are done.

To operate with greater than 64k offsets requires the leap into 32bit
programming and protected modes.

Ohh, the variable shift thing..
If you increment a segment value by 1, you are really adding 16 (10h) to the
linear address. Its a nibble shift, 4 bits. This is done in the cpu address
decoder, no changing it.

You want a 5 bit shift for some reason. A five bit shift for the segment value
yields 20h increment in the linear address, a 32 byte resolution verses a 16
byte resolution for a nibble shift of 4.

To get an effective 5 bit shift, shift (DS,ES) left by 1 to get your 32 byte
resolution, the natural nibble shift of 4 plus 1 by your adjustment.

Something nags me that we're not on the same line of thinking tho.

hth,
Steve

[muta...@gmail.com]

You have raised two technical points I would like to address.

First of all, I'm not claiming I would have
done a better job if I had been around in
the 8080 timeframe.

I am not under time and financial
pressure, and I have had decades to
think about things, plus the feedback of
real world problems that can be
traced back to these decisions.

So first we have the justification for address wrap.
So that call 5 could be implemented.

Perhaps we need to go back to the 8080
and/or cp/m to see whether the call 5
could have been replaced with something
that could have future-proofed the
situation.

Then we can say even if the 8080 and
cp/m can't be changed, what could have
been done in the 8086 to recover from the
situation?

E.g. if we need address wrap, maybe there
could have been a different call instruction
such as callwrap. On the 8086 call and
callwrap would be identical, but when
you have an 80286, callwrap behaves
differently.

Finally, your suggestion to get a 5 bit
segment shift by shifting the segment register
by 1 bit completely misses my reason
for wanting to shift 5 bits. It is
not because I think 32 byte granularity
is better than 16 byte granularity,
it is because I want an 8086+ to
address 2 MB of memory instead of 1 MB.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Monday, September 12, 2022 at 4:23:43 AM UTC+8, s_dub...@yahoo.com wrote:
> > On Sunday, September 4, 2022 at 1:55:32 PM UTC-5, muta...@gmail.com wrote:
> > > On Monday, September 5, 2022 at 1:03:24 AM UTC+8, Scott Lurndal wrote:
> > > > "muta...@gmail.com" <muta...@gmail.com> writes:
> > > > >On Sunday, September 4, 2022 at 9:25:34 PM UTC+8, wolfgang kern wrote:
> > > > >> On 04/09/2022 06:32, muta...@gmail.com wrote:
> > > >
> > > > >Noone had done segmentation before and it
> > > > >would take decades of science still to
> > > > >work through the repercussions.
> > > > Several very successful systems that predate the
> > > > 8086 by a full decade used segmentation; examples include the PDP-11,
> > > > the B6500 et alia.
> > > They presumably didn't do 4 bit shifts or similar
> > > so didn't hit the a20 issue nor the flexible shift issue.
> > >
> > > The a20 is probably because of cp/m PSP though,
> > > not segment shift.
> > They presumably didn't do 4 bit shifts or similar
> > so didn't hit the a20 issue nor the flexible shift issue.
> >
> > The a20 is probably because of cp/m PSP though,
> > not segment shift.
> > ~~~
> >
> > Gosh, istm you have these concepts jumbled up.
> >
> > Sorry for the review but..

<snip>

>
> So first we have the justification for address wrap.
> So that call 5 could be implemented.
>
> Perhaps we need to go back to the 8080
> and/or cp/m to see whether the call 5
> could have been replaced with something
> that could have future-proofed the
> situation.

No "perhaps". Call 5 was for CPM compatibility. Original
CPM was for 64kB address space, so no problem _preserving_
compatiblity with respect to segment manipulation/wraparound:
this was new stuff. 8086 was different instruction set
so if was possible to implement equivalent functionality
in different way.

Even if you insist on having exactly the same functionality,
in PSP it is easy to do without wraparound: just put extra far
jump at end of BIOS ROM and in PSP have jump to this extra jump.
Cost is extra 4 bytes of ROM used by the jump and extra
machine cycles to execute extra far jump per each call 5.

Of course, once BIOS without this extra call was in the wild
DOS had to support such BIOS-es and gate A20 was logical
solution...

--
Waldek Hebisch

[muta...@gmail.com]

Even if gate a20 was a logical solution,
would it have been reasonable for msdos to
have an explicit bios call to enable wraparound?

Even if existing bioses don't implement that
call, it doesn't matter, because the 8086 is
going to wrap around anyway.

It's only when the 80286 arrives that the
bios call needs to actually work.

[muta...@gmail.com]

Actually, there could be one bios call to query
whether the bios has those dedicated 4 bytes.

If that returns success, then that is what
is used for call 5.

Otherwise, a bios call is done to disable a20.

Unless you are on a machine with more than 1 MB
of memory, in which case the high memory
area is populated with those 4 bytes.

Actually, why is disabling a20 ever
needed? Won't you always be in a position
to populate high memory if it exists,
and if it doesn't, there's no issue anyway.

This is why I like to discuss things.

I can't derive anything in a vacuum.

[wolfgang kern]

On 13/09/2022 14:21, muta...@gmail.com wrote:
[...]

>> Even if gate a20 was a logical solution,
>> would it have been reasonable for msdos to
>> have an explicit bios call to enable wraparound?

back then there were a lot (also non-M$) programs around
which relied on wraparound for a reason:
catch any overrun to indicate an error.

you can see overrun/wrap also on segments, it became
handy to restart code at offset zero with two bytes
at the end of a code segment [FFFE: EB 00 jmp 0000].

But even this looks similar to A20 warp it is another
story.
the top of the last 64K in the 1MB range belong to BIOS
which is/was ROM anyway.

>> Even if existing bioses don't implement that
>> call, it doesn't matter, because the 8086 is
>> going to wrap around anyway.

my early OS (~1985..1997) didn't use the BIOS for
A20 check and enable, it just talked the hardware.

...

> Unless you are on a machine with more than 1 MB
> of memory, in which case the high memory
> area is populated with those 4 bytes.

what four bytes to you mean here?
"far" CALL/JMP are 5 byte within 16-bit.

> Actually, why is disabling a20 ever
> needed? Won't you always be in a position
> to populate high memory if it exists,
> and if it doesn't, there's no issue anyway.

I never used a disabled A20, mine were always ON
it's just a historical remain (aka tomb stone).

> This is why I like to discuss things.
> I can't derive anything in a vacuum.

if this is a question I haven't got the sense :)
__
wolfgang
the day when an M$-product wont suck is the day
when they start producing vacuum cleaners.

[muta...@gmail.com]

On Tuesday, September 13, 2022 at 12:24:43 AM UTC+8, anti...@math.uni.wroc.pl wrote:

4 bytes of ROM or 5 bytes? My understanding
from Wolfgang is that 5 bytes are required.

[wolfgang kern]

On 13/09/2022 22:22, muta...@gmail.com wrote:

> 4 bytes of ROM or 5 bytes? My understanding
> from Wolfgang is that 5 bytes are required.

perhaps these four bytes came from old school :)
if the BIOS support functions via INT then only 4 bytes:

B4 xx MOV AH.xx
CD yy INT yy
__
wolfgang

[anti...@math.uni.wroc.pl]

Yes, 5 bytes.

--
Waldek Hebisch

[s_dub...@yahoo.com]

Ohh, how about an INT call, msdos claimed int's in the range of 20h..2Fh
in other parts of the code. An int is a far call plus saving of the flags.

Because msdos used ints why did they keep call 5?
Why didn't the OEMs just say 'Fix your code!'.

The 8080 is different enough to let it lay, and move on.

> Then we can say even if the 8080 and
> cp/m can't be changed, what could have
> been done in the 8086 to recover from the
> situation?

Rewrite the code, it couldn't have been impossible.?

>
> E.g. if we need address wrap, maybe there
> could have been a different call instruction
> such as callwrap. On the 8086 call and
> callwrap would be identical, but when
> you have an 80286, callwrap behaves
> differently.
>
> Finally, your suggestion to get a 5 bit
> segment shift by shifting the segment register
> by 1 bit completely misses my reason
> for wanting to shift 5 bits. It is
> not because I think 32 byte granularity
> is better than 16 byte granularity,
> it is because I want an 8086+ to
> address 2 MB of memory instead of 1 MB.

Ok.
But 2mb addressing requires adding an address line to the cpu and buss.
And that wasn't going to happen.
Because the 80286 and 80386 were already under design and development.
This began the situation of software capabilities trailing hardware capabilities.
Because hardware began its exponential development.
And software was looking at backward compatibility at each step.

Steve

[muta...@gmail.com]

That's a good point. If they knew the problem they
were about to create, maybe they would have done that.

But while we're here, would it have been possible to
create an 8080 that wasn't so different from the 8086
that there would be an expectation of binary
compatibility?

If so, the solution of fixing code won't work, we'll need
a proper design.

I don't need the 8086 itself to have an extra address line.
It is sufficient to add flexible segment shifts to the 80286
and 80386 for virtually no cost.

And I'm not concerned about political barriers.

But a slight change to the 8086 in preparation for
the 80286 would be ok.

What do you recommend?

[Joe Monk]

> But while we're here, would it have been possible to
> create an 8080 that wasn't so different from the 8086
> that there would be an expectation of binary
> compatibility?
>

> What do you recommend?

A chip by NEC called the V20/V30. It could run both 8080A and 8086 code... (V20 = 8 bit bus, model uPD70108, V30 = 16 bit bus, model uPD70116) It was binary compatible with both the 8080A and the 8086.

"The uPD70108/70116 has two CPU operating modes: native and 8080 emulation. In native mode, the uPD70108/70116 executes all the instructions given in Section 12, with the exception of the RETEM and CALLN instructions. In 8080 mode, the microprocessor executes the instruction set for the uPD8080AF and the RETEM and CALLN instructions. These modes are selected by special instructions or by using an interrupt. The most significant bit of the PSW is a mode (MO) flag that controls mode selection."

https://ia903205.us.archive.org/28/items/bitsavers_necV20V30U_11351331/V20_V30_Users_Manual_Oct86.pdf

Joe

[muta...@gmail.com]

I don't think this is what I'm looking for.

I don't want either 8080 or 8086.

I'm after a subset of 8086 to replace the 8080.

In the same way that zarch can run s/390
instructions.

No mode change required.

[anti...@math.uni.wroc.pl]

I do not understand why you do not want mode bits? In 8086 prefix
changes meaning of the following instruction. Similarly, mode
change affects meaning of following instructions. You may
object that prefix affects only single instruction, but it
is really artificial distinction. In 387 there is rounding
mode which affect all instructions after mode change.
Similarly direction flag affects following instruction.
Logically, one can treat processor flags as mode bits that
that change meaning of following instructions. For example
in "no-carry" mode JNC is just a NOP, in "carry" mode JNC
acts as plain jump.

So are you going to forbid 387 and direction flag? I suspect
that you are not going to forbid conditional jumps, as that
would make 8086 essentially useless (one could still implement
control using modification of targets of indirect jumps, but
that would be extremally awkward). Note that thare are
processors without flag bits, IIUC MIPS is an example of
such processor. So if you trurly dislike mode bits maybe
you should use MIPS?

--
Waldek Hebisch

[Scott Lurndal]

MIPS has plenty of mode bits in CP0 registers. It doesn't
track the traditional conditional flags (NZCV, Q) in a register because
it folds a COMPARE and a CONDITIONAL BRANCH into a single
instruction.

[muta...@gmail.com]

I want a tiny memory model program to run on
an 8086 at let's say the 64k location, which would
mean the segment registers are all loaded with
0x1000

The processor is not aware of the contents of
that tiny memory model program so doesn't know
it needs to switch mode.

Even if it did switch mode, the segment registers still
need to work, otherwise memory at location 0
would be accessed instead of memory at
location 64k.

Perhaps you could have logic in the os that
got it to switch mode before calling the
com file. But then you couldn't have a com file
with 8086 instructions, only 8080.
And then you need a way of calling os services,
at which point you need to switch mode back
to 8086. Can it be done? Maybe.
But it's a lot more complexity to add to
both the NEC chip and msdos.

When I was being chided for even wanting
to add a single instruction to the 8086.

I haven't really thought through the 8086,
but there is another environment
that interests me - zarch.

I wish to run 32 bit s390 programs,
unmodified, at the 4 GB location.

To do that the os does need to be aware
that it is a 32 bit not 64 bit program,
but I don't have a problem with that, because
32 and 64 are very distinct needing
different fixups.

The os then needs to load certain registers with
1 in the high 32 bits, indicating the 4 GB
location. Other registers will be loaded with
0 in the high 32 bits. These are data registers.
The former were address registers.

Actually I'm not sure if everything can be
loaded with 1. I think it can. I discussed this
3 years ago or something but I've
forgotten some details.

Programs and os need to be changed,
but that's fine, that's what pdos-generic is for.
You can't do an svc, I can't remember why.

I don't care if the compiler needs to be
changed and I don't care that programs
need to be recompiled.

We can discuss s390 if you want, but it was already
discussed to my satisfaction.

My goal at the moment is to make
a modified 8080 to x64 as good as
the unmodified s390 to zarch.

Actually I might modify the s390 to make it
32 bit, but zarch doesn't need modification,
it can already do 32 bit addressing,
effectively.

[anti...@math.uni.wroc.pl]

IIUC NEC chip uses segementation in 8080, namely when
switching modes you give it segement and start address
to use and it runs in specified segment. I did not read
the whole description, but at first glance it works
quite nicely: interrupts switch it 8086 mode and
retrun from interrupt restores mode.

> When I was being chided for even wanting
> to add a single instruction to the 8086.

Well, real problem is gain for the effort. NEC obtained
something of clear value: ability to run both 8080 and
8086 programs. Of course, one can discuss how valuable
it was. Around 1992 our department had bunch of PC-s
equipped with V20 (or maybe V30). They were used as
ordinary PC-s, I am not aware of anybody using 8080 mode.
But when V20 was introduced it probably was more attractive...

> I haven't really thought through the 8086,
> but there is another environment
> that interests me - zarch.
>
> I wish to run 32 bit s390 programs,
> unmodified, at the 4 GB location.

But you really did no say why? Why do you care
at which address program is loaded? Normally
people care that program works correctly. And
paging hardware was introduced to allow loading
program in arbitrary area of memory (so that you
have no trouble when two program want to use
"the same address" in conflictiong ways).

Hmm, if you are satified with recompilation, then modify
your favorite C compiler to generate x86_64 instructions, but
operate on 16bit, 32bit or 64-bit data as appropriate.
To emulate segmentation dedicate one (or few) registers
as base registers (my impression was that the compiler left
a lot of registers with no use so you can easily find
free registers).

OTOH, when I compile a program I want to compile it for right
architecture, so for running on x86_64 I use 64-bit mode.
On Arm ATM I mostly use 32-bit mode because most of my Arm
machines are 32-bit.

I think I already mentioned project which wanted to use
64-bit instruction encoding but limit data to 32-bits.
Motivation for this was that 64-bit instructions are
more efficient than 32-bit ones (mostly due to extra
registers) but 64-bit data requires more work than
32-bit data. IIUC there was (is??) (at least preliminary)
support in gcc and Linux, but it seems that the project
stalled, and that there is to little demand to justify
the effort.

IIUC you do not mind few percent loss of efficiency
(in fact, several yours ideas would bing much larger
efficiency loss), in such case there is really no
reason to compile for non-native targets. OK, you
could do what Apple is now doing: compile to portable
bytecode that can be easily "converted" to native
code. "converted" here really means that compilation
is split into stages and last compilation stage is
done as "installation" or even at runtime.

--
Waldek Hebisch

[anti...@math.uni.wroc.pl]

Yes. My point was that normal progrem run on PC fiddles with
mode-like bits. IIUC on MIPS you can set modes once (say in
OS) and than run program without touching anything like modes.

Of course, when Paul learns that that there are mode bit on
MIPS he will want to run programs compiled for different
modes without changing mode bits, so you are right, the
problem would come back...

--
Waldek Hebisch

[Joe Monk]

"I wish to run 32 bit s390 programs,
unmodified, at the 4 GB location."

Not possible. First off there is no such thing as a 32-bit s390 program. The instructions BXLE and BXH on the s390 perform signed arithmetic to accomplish their purpose.

This precludes 32-bit on the s390.

"The word "index" in the names of these instructions indicates that one of the major purposes is the incrementing and testing of an index value. The increment being a signed binary integer, may be used to increase or decrease the value in general register R1 by an arbitrary amount."

Joe

[muta...@gmail.com]

You may as well say that 64 bit is
excluded on zarch for the same reason.
The g version of those instructions encounter
the same problem for the top 50%
of the address range.

Also, for both zarch and s390 the problem
also occurs in the bottom 50% - when
you NEAR the end.

It is thus a simple matter of never using
those instructions when you are using
addresses instead of numbers.

gcc 3.2.3 never used those instructions,
which is all I care about.

Yes Dorothy, you can run 32 bit
programs on zarch and you can make
a modified s390 too if you want.

Zarch is perfect if you take the above precautions.

Perfect for both 32 bit and 64 bit.

[muta...@gmail.com]

Several points.

On zarch I want to be able to run a 32 bit program
that uses say 3 GB of data, and then do a system ()
to run another 32 bit program that also uses
3 GB of data.

I don't want to rely on virtual memory existing.
I'm just going to give it 12 GB of RAM.

With the x64 I don't want to rely on x64
existing. I want to hold 8086 constant, or
near-constant, and change the 8080.

Or are you saying you could design an 8080
replacement, in the 1970s, that would
use the x64 instruction subset?

I'd be happy with that, although it
was the 80386 I wanted to hold near-constant.
I don't really care about the x64.

And actually it is the 80386ex that
I care about. No segments, no v86 crap etc.

But I can switch from 80386ex to x64
if necessary.

I didn't understand your comment about no
reason to compile for a non-native target.
Can you give an example?

With regard to the NEC adding value,
that is not what I'm after either.

I'm interested in a similar number of
transistors in the 8080 replacement as the 8080.

A similar number of transistors in an 8086+
compared to 8086.

I don't need the modified 80386ex to
run segmented 8086 programs.
I expect people to recompile for the
80386, or for the 80386 to have 2
modems.

I do expect 8080-replacement aka tiny
memory model 8086 programs to run
on the 80386.

Zarch can do it, why not 80386?

(There may be a reason, I don't know)

Maybe coexistence of 32 and 64 is
easier than coexistence of 16 and 32.

[Joe Monk]

> Yes Dorothy, you can run 32 bit
> programs on zarch and you can make
> a modified s390 too if you want.
>

Nope. In z/arch and s390, only 31 bits are looked at as the address... And the address wraps at 31 bits.

Joe

[muta...@gmail.com]

Wrong. In zarch, in am64, 32 bit programs
don't wrap.

You're right about s390, but not right if
you're suggesting it's not possible to
create a modified s390.

[muta...@gmail.com]

Just thinking about it some more.

What I would expect, at a minimum, is for
tiny memory model 8086 programs, and
the 8080 replacement, to run in the lower
64k of memory.

Then 80386 ex programs to run in the lower
4 GB of memory, and x64 programs to
run above 4 GB, and below is also fine.

Could be modified x64 too.

And modified 80386 EX for that matter.

Basically, what is proper/ideal design,
inspired by 80386 ex.

And then we can discuss whether some
compromise can be made to deal with
what actually happened with real processors.

That compromise could be doing things like never
using bxle on s390, or something like that.
The x86 equivalent.

Or modifying Bochs and/or seabios.

And then suggesting to AMD that they
modify the next generation of chip.

I'm not expecting AMD to listen, but I am
happy to put a solution in their lap and
say I did my best.

That's a possible outcome, but I don't
have fixed goals.

I could instead switch to adding 16-bit
instructions to the perfect zarch.

But I'd like to understand 8, 16, 32, 64
on x86 first, as that has real-world feedback
to learn from.

[Joe Monk]

> Wrong. In zarch, in am64, 32 bit programs
> don't wrap.
>
> You're right about s390, but not right if
> you're suggesting it's not possible to
> create a modified s390.

Hercules is the hercules team's own implementation of a software defined machine that can execute the IBM instruction set. Hercules is not s/370. Hercules is not s/390. Hercules is not z/Arch. When you monkey around with hercules, all you are doing is changing the way the hercules VM executes. You are not in the least changing anything about the way IBM does/did it, nor are you changing the specs for an IBM architecture.

So, if you want to say it's possible to create a modified hercules, then sure. But thats all it is, a modified hercules.

"Hercules is compliant with IBM's ALS-1, ALS-2 and ALS-3 architectural level sets to the degree necessary to run all OS/390 versions through 2.10 and known versions of z/OS in both ARCHLVL 1 and ARCHLVL 2 mode, and Linux and z/VM in both ESA/390 and z/Architecture mode."

Joe

[s_dub...@yahoo.com]

Yes it was so different. In segmentation and relative addressing, and a host of other things.
The 8080 was a glorified 8008, a programmable micro-controller used for traffic light operation.
The program it ran was static, held in ROM.
The recognition that the 8080 was a generalized computing device was novel.
Kildall raised cp/m-80 on the intel MDS, micro-controller development system.
The appearance of the floppy disk technology made it useful as a generalized computing device.
Various programs were now loaded in RAM, and storage (on floppy) was now dynamic.

I recommend programming on attainable hardware.
I favor using the x86 environment supported by the CM Compatibility Module (real mode bios support),
on a 64 bit platform. And graduating to protected mode/long mode.

This side-bar is interesting but.. practical?
Steve

[muta...@gmail.com]

I didn't mention Hercules and I didn't say
I could force IBM to do something and
I didn't say I could magically change
existing s/390 processors. Nor did I
say I could force IBM to make
documentation changes.

What I said was:

1. 32 bit programs can run on an
unmodified zarch in am64.

2. It would be possible for someone,
not necessarily IBM, to make a slight
modification to a s390 chip, to make
it run 32 bit programs that access the
entire 4 GB.

If you dispute either of these technical,
not political, statements, then tell me
which one and very clearly why, so
that we can attempt to come to a
common understanding.

[muta...@gmail.com]

The practicality may or may not kick in
after the Russians start a nuclear war after
being frustrated and humiliated in Ukraine.

The only people who may still be able to
manufacture chips may be universities,
and they can only manage 8 bit processors.

So this is where we need a replacement for the
8080. We will have existing x64 computers,
which means both 80386 and x64 will be
available if either is useful.

But building a 32 bit computer instead
of an 8 bit computer will be a dream
for another day.

Before we even start on practicalities,
I would like to understand the theoretical underpinnings,
using the 80386 ex as an aid to
understanding.

I don't actually know anything wrong with
the 80386 ex, but I don't know very much,
so that doesn't mean much.

My understanding is that there is
indeed something wrong, because you
can't add 64-bit addressing/instructions
to the 80386 unless you change
modes. Unlike being able to run both
32 and 64 bit programs on zarch with
no mode change required.

I believe you can backdate x64 and write
32 bit programs in long mode, but
they won't run on an 80386. I don't
know why.

It is possible that Intel and amd got
everything right from day 1, and that
even with the benefit of hindsight there is
nothing that can be faulted.

And thus in any reconstruction process
we should create an exact 8080 plus
try to find that software that translates 8080
to 8086.

Hell, even if we can find fault, that may
still be the most practical route.

But I want to start by understanding the
theoretical underpinnings.

I've already identified what looks
to me to be bad design decisions.

1. Not making the 8080 compatible
with a future 8086.

2. Not allowing a flexible shift value
in the 8086, at a minimum in documentation.

3. Not implementing that flexible shift
for close to 0 cost in the 80286.

4. Not having a bios call to retrieve the shift value.

5. MSDOS not having a call to retrieve the shift
value, or even better, having a call
to manipulate huge pointers to
allow huge memory model applications
to run on either rm16 or pm16.

Once I understand the theory about how to
do things cleanly, noting that I don't
see anything unclean about zarch,
but do see unclean things necessitating
the concept of am24 and am31, I
will be in a position, post nuclear war,
to either suggest how universities
can start manufacturing chips with
0 known theoretical flaws, or make
compromises, but perhaps compensate
for those flaws with preemptive
software recommendations.

Maybe.

I don't even properly understand the
current state we are in, nor do I
know if that was necessary.

[Joe Monk]

> 1. 32 bit programs can run on an
> unmodified zarch in am64.

AM64 is 64 bit, not 32 bit. If youre in AM64, then by definition, your program is 64 bit. Instruction and storage addresses are 64 bits wide, not 32 bits wide.

Joe

[muta...@gmail.com]

At some level that is technically true.

But the program that I am talking about is using
purely 32 bit instructions, purely 32 bit
registers, and writing data in 32 bit
amounts, which is 32 bit by definition.

Unless you want to provide a different
definition of 32 bit.

It will also run on a slightly
modified 32 bit alternative
processor, no 64 bit in sight.

It will also run on a real s390,
but because of address line limits
it will only access 2 GB storage.

And it will even run on an
unmodified s370, but again, address
lines will limit it to 16 GB of storage.

The fact that a 32 bit program has
an extra 32 unused address lines on
zarch, all set to zero by the os,
1 address line that can't be used on
an existing s390, 8 address lines
that can't be used on an existing s370,
does not stop a 32 bit program from
being a 32 bit program.

Unless you want to start a semantic
debate, which I will probably simply
concede, because my only real
interest is the concept that 32 bit
programs, my possibly faulty definition,
can run on zarch accessing the full
4 GB that 32 bit is capable of.

[s_dub...@yahoo.com]

Seems like the same 1949 thinking as:
Surviving Atomic Attack
https://www.youtube.com/watch?v=ccBipSFdB5g
Interesting bomberairplane depiction.

More likely you'll be wishing for an abacus and slide rule.

> So this is where we need a replacement for the
> 8080. We will have existing x64 computers,
> which means both 80386 and x64 will be
> available if either is useful.
>
> But building a 32 bit computer instead
> of an 8 bit computer will be a dream
> for another day.
>
> Before we even start on practicalities,
> I would like to understand the theoretical underpinnings,
> using the 80386 ex as an aid to
> understanding.
>

I don't know what 'theoretical underpinnings' means.
Perhaps you consult with electrical engineers involved in the design.

Certainly, the number of transistors they could work with (fit on the die)
was the limiting factor in the design. This, 'density' was where the action
was in terms of Moore's Law..
https://en.wikipedia.org/wiki/Moore%27s_law

With density came more features, one was adding the math co-processor
to the cpu die for speed improvement over having the math co-processor
as a separate chip. There are many more features added as time progressed.

Computer scientists wanted separate Code and Data, CS & DS, as mentioned before.

> I don't actually know anything wrong with
> the 80386 ex, but I don't know very much,
> so that doesn't mean much.
>
> My understanding is that there is
> indeed something wrong, because you
> can't add 64-bit addressing/instructions
> to the 80386 unless you change
> modes. Unlike being able to run both
> 32 and 64 bit programs on zarch with
> no mode change required.
>
> I believe you can backdate x64 and write
> 32 bit programs in long mode, but
> they won't run on an 80386. I don't
> know why.
>

You could benefit your understanding if you got the manuals
for each processor and do a cursory comparison of the features
they offer. And the 'backward compatibility' efforts they made.

> It is possible that Intel and amd got
> everything right from day 1, and that
> even with the benefit of hindsight there is
> nothing that can be faulted.
>
> And thus in any reconstruction process
> we should create an exact 8080 plus
> try to find that software that translates 8080
> to 8086.
>
> Hell, even if we can find fault, that may
> still be the most practical route.
>
> But I want to start by understanding the
> theoretical underpinnings.
>
> I've already identified what looks
> to me to be bad design decisions.
>
> 1. Not making the 8080 compatible
> with a future 8086.
>

It would take a seer to forecast 'fore-ward compatibility'.

Stylistically, they both have:
An Accumulator - AF AX
An index register - HL BX and BP
A Stack Pointer - SP SP
A Program Counter - PC IP
A data register - DE DX
A data register - BC CX
So, there is some synergy there.

Although alot of programming wizardry was done in 61k the
future of 'bigger data' space was going to swap the 8080
abilities.

> 2. Not allowing a flexible shift value
> in the 8086, at a minimum in documentation.
>
> 3. Not implementing that flexible shift
> for close to 0 cost in the 80286.
>
> 4. Not having a bios call to retrieve the shift value.
>
> 5. MSDOS not having a call to retrieve the shift
> value, or even better, having a call
> to manipulate huge pointers to
> allow huge memory model applications
> to run on either rm16 or pm16.
>

2..5
The 'variable shift' concept totally escapes me.
Is it not possible that the cpu can already accomplish it, in other terms?
At the end of the day, the addressing modes resolve to a linear address.
The thrust of the various modes are to protect code and data.
The implementor has variety of choices. I'm not sure if this is a good
thing due to the added complexity for the programmer. But the commitment
to 'backward compatibility' was a factor.

> Once I understand the theory about how to
> do things cleanly, noting that I don't
> see anything unclean about zarch,
> but do see unclean things necessitating
> the concept of am24 and am31, I
> will be in a position, post nuclear war,
> to either suggest how universities
> can start manufacturing chips with
> 0 known theoretical flaws, or make
> compromises, but perhaps compensate
> for those flaws with preemptive
> software recommendations.
>
> Maybe.
>
> I don't even properly understand the
> current state we are in, nor do I
> know if that was necessary.

A 1949 frame of view, ah but we're some seven decades past that..

Steve

[Scott Lurndal]

"s_dub...@yahoo.com" <s_dub...@yahoo.com> writes:
>On Tuesday, September 20, 2022 at 3:54:34 PM UTC-5, muta...@gmail.com wrote:

>> The practicality may or may not kick in
>> after the Russians start a nuclear war after
>> being frustrated and humiliated in Ukraine.
>>
>> The only people who may still be able to
>> manufacture chips may be universities,
>> and they can only manage 8 bit processors.
>>
>Seems like the same 1949 thinking as:
>Surviving Atomic Attack
>https://www.youtube.com/watch?v=ccBipSFdB5g
>Interesting bomberairplane depiction.
>
>More likely you'll be wishing for an abacus and slide rule.

More likely he'll be wishing for something to eat and drink.

[muta...@gmail.com]

On Thursday, September 29, 2022 at 1:13:56 AM UTC+8, s_dub...@yahoo.com wrote:

> > The practicality may or may not kick in
> > after the Russians start a nuclear war after
> > being frustrated and humiliated in Ukraine.
> >
> > The only people who may still be able to
> > manufacture chips may be universities,
> > and they can only manage 8 bit processors.
> >
> Seems like the same 1949 thinking as:
> Surviving Atomic Attack
> https://www.youtube.com/watch?v=ccBipSFdB5g
> Interesting bomberairplane depiction.
>
> More likely you'll be wishing for an abacus and slide rule.

Currently I live in rural Philippines. Under a certain theory,
Manila and Quezon will be nuked to eliminate the
industrial capability, but I will be fine. The video you
linked started with large populations, so not relevant.

Food is probably not going to be a problem here either,
especially with rice farms still be farmed by hand.

Maybe I should take a photo of a carribou walking
past my house too.

There is a manual water pump for a well about 60
meters from my house. And owned by my wife
actually. It was built by my father-in-law and gives
our neighborhood access to free water.

I'm sure there will be problems, maybe even
cannibalism, which I may or may not survive.

The Philippines has a concept of a "debt of
gratitude", and my father-in-law is elected as
a councilor because he has a reputation for
helping others.

Hopefully that counts when people are deciding
who to eat.

Assuming I survive, my multiple (about 20 or so)
phones capable of running PDOS on ridiculously
low energy will survive. Unfortunately the solar
power I have produces even more ridiculously low
energy. But I just realized I have a new solar to
experiment with, so maybe I should see if that is
better.

Regardless, the power is non-zero, meaning work
on PDOS/86 can be done in preparation for
new chips produced by universities.

Maybe I need to find the nearest university that has
that capability. I suspect no Philippines university has
that capability, but regardless, it is beyond the scope
I have set for myself to organize boats to acquire
chips from Taiwanese universities or whatever.

> > Before we even start on practicalities,
> > I would like to understand the theoretical underpinnings,
> > using the 80386 ex as an aid to
> > understanding.
> >
> I don't know what 'theoretical underpinnings' means.
> Perhaps you consult with electrical engineers involved in the design.

No, I do not wish to be involved on the hardware side,
except for some basic questions like what's the extra
cost of the 8086 if variable shifts are added? Which
has already been answered, which is 5%.

It is the software side I am interested in.

> Computer scientists wanted separate Code and Data, CS & DS, as mentioned before.

There's no sensible alternative for the segmentation
model, is there?

> > I've already identified what looks
> > to me to be bad design decisions.
> >
> > 1. Not making the 8080 compatible
> > with a future 8086.
> >
> It would take a seer to forecast 'fore-ward compatibility'.

Sure. I'm not claiming I could have done a better job
if I had been there at the time.

I'm suggesting that we as a group, could identify, with
the benefit of hindsight, what the flaws were.

Then we could construct an x86-inspired path from
8 bit to 64 bit that eliminates all the flaws we believe
we have identified.

I know there are voices who call for totally replacing
x86 with RISC-V or whatever, but that can be a parallel
effort, which I may join at a later date.

In the Philippines, smartphones are ubiquitous, but PCs
are not. You can get external USB keyboards for 96 pesos,
about US$2. Yesterday I made an order for 10 of them.

I have heard people say don't try to program on a
smartphone - you need a PC.

I think I didn't have a smartphone at the time, so
didn't know what the issue was.

Since then I have programmed on PDOS even without
an external keyboard and was successful.

With an external keyboard requires positioning, but
once positioned seems fine. I haven't written an
actual program though.

Regardless, for an addition maybe US$5 including
adapter you can likely turn your smartphone into
a PC. I did find one Android that wouldn't start
PDOS under Bochs. It crashed. Othere phones also crashed,
but the workaround was to rename vhd to img.

Another workaround that may be required is to
change the file selection from system to in-app.

It would be nice if I could point this out to the
education system, and they encouraged people to
spend US$5 to get PCs for computer classes.

But it probably won't happen.

Regardless, there will be surviving PCs, but needing
a lot of power, and mains power that probably doesn't
exist. But some people have solar power, so they
could run a real PC.

As hardware dies, there will be no replacements.

The replacements on the horizon will be 8 bit ones
from universities.

I may not be involved in that. I'll stick with
working on PDOS/86 under emulation until all 20 of
my phones give out.

But I will touch base with the universities and let
them know that if they head in a particular direction,
they will have access to a clean OS for low capability
PCs.

Not crappy posix that relies on VM existing.

But my clean design comes at a cost, which is that
it realistically requires 2 MiB of memory to do
what Freedos can do in 1 MiB. At least worst case
scenario. I have another design (pdos-generic) that
may match Freedos.

So if the new industry goes down a path from 8 bit
to 16 bit, that, just like in the real world,
sees people running MSDOS when actually there is
much more than 1 MB of memory available, but their
app is restricted to 640k, PDOS/86 would have its
chance to shine. The universities just need to
provide a flexible shift, or even a fixed 5-bit
shift, and I'll have what is needed. Fixed 5-bit
will still be limiting, but it won't rule PDOS/86
out.

> Stylistically, they both have:
> An Accumulator - AF AX
> An index register - HL BX and BP
> A Stack Pointer - SP SP
> A Program Counter - PC IP
> A data register - DE DX
> A data register - BC CX
> So, there is some synergy there.

But can you answer the question - can that
synergy be total, so that the 8080-replacement
can be a subset of the 8086, or would both
processors need some adjustment?

> Although alot of programming wizardry was done in 61k the
> future of 'bigger data' space was going to swap the 8080
> abilities.

Sure. There is no question of following the path
from 8 bit to 64 bit.

Some people dispute introducing segmentation as
a somewhat temporary road along that path, but
I'm not one of them.

> The 'variable shift' concept totally escapes me.
> Is it not possible that the cpu can already accomplish it, in other terms?
> At the end of the day, the addressing modes resolve to a linear address.

The 80286/80386 can accomplish the equivalent of a
variable shift, if you line up the selectors, and
you prepare for this in your programming, including
the OS.

And I intend to do this too.

But the 80286 is much more difficult to produce than
a modified 8086 that does 5-bit shifts. I don't want
to rule that out either. And to me that is a very
logical/clean thing to do regardless. Unless you can
prove via maths that 4 has some magical power. Even
if someone produces an 8086 that has 4 hardcoded,
zero chance of changing it, which indeed is exactly
the case in real life, that's no reason for the
software, including the OS, to treat the number 4
as holy writ.

Even though no-one did, there was never any barrier
to someone producing an 8086-5 that did 5-bit shifts.

And with FPGA, maybe the "no-one did" will change.
Even if it is just for fun. And with Bochs or
equivalent it becomes even more possible.

> > I don't even properly understand the
> > current state we are in, nor do I
> > know if that was necessary.

> A 1949 frame of view, ah but we're some seven decades past that..

I'm not sure where we are, or even who "we" is.

BFN. Paul.

(Yay, I can touch-type again!)

[s_dub...@yahoo.com]

You say that, yet all this talk of changing microprocessor functionality for
'variable shift' -and other things.

Please change your nomenclature in regards to 'shift 5'.
It is confusing and irksome to assembly programmers who know that there are
bit shifting instructions for doing shifting of values in registers and memory.
You are discussing changing how address decoding should optionally work
regarding segment registers in real mode address decoding.

When I said segment register value is translated 'AS IF' the segment value is
shifted left 4 bits and the IP offset is added to it for the purpose of
address translation to a linear address, I didn't mean that shift 4 is some
sort of variable, or available to be changed, just to be clear.

> > Computer scientists wanted separate Code and Data, CS & DS, as mentioned before.
> There's no sensible alternative for the segmentation
> model, is there?

Long mode with paging??
I have not done any x64 programming so I'm not up to date on what's being done.

Support & implementation of segmentation was a natural 'next step' from the
single segment 8080 where code, data, stack was comingled. And comingled
again; application and operating system in the same segment.
The 8080 was a micro-controller coerced into a generalized computing device.
The 8086 was a micro-processor, "a microcomputer" -as Intel called it, it was
the next step in technology.

The method of addressing, of the two, is quite different.
In the code snippit:
jmp next
jmp next
jmp next
next:
nop

The 8080 treats 'next' as an immediate address where the bytes code of 'next'
are all the same.
The 8086 treats the encoding of 'next' as the distance from the current IP to
the target 'next' so the bytes coding of the three jmp's are different.
The 8086 supports 'position independent code'.
It is also PIC with regards to segment value. It will run as designed, in its
binary form, whether loaded at segment 0050h, 0060h, -any segment.

As a sidebar, assemblers for the 8080 began to support aggregating code snippets
together followed by data snippits, if that is what the progammer wanted. So
the under-pinings of segments showed up in the software tools back then.

> > > I've already identified what looks
> > > to me to be bad design decisions.
> > >
> > > 1. Not making the 8080 compatible
> > > with a future 8086.
> > >
> > It would take a seer to forecast 'fore-ward compatibility'.
> Sure. I'm not claiming I could have done a better job
> if I had been there at the time.
>
> I'm suggesting that we as a group, could identify, with
> the benefit of hindsight, what the flaws were.
>
> Then we could construct an x86-inspired path from
> 8 bit to 64 bit that eliminates all the flaws we believe
> we have identified.
>
> I know there are voices who call for totally replacing
> x86 with RISC-V or whatever, but that can be a parallel
> effort, which I may join at a later date.
>
> In the Philippines, smartphones are ubiquitous, but PCs
> are not. You can get external USB keyboards for 96 pesos,
> about US$2. Yesterday I made an order for 10 of them.
>
> I have heard people say don't try to program on a
> smartphone - you need a PC.
>
> I think I didn't have a smartphone at the time, so
> didn't know what the issue was.
>
> Since then I have programmed on PDOS even without
> an external keyboard and was successful.
>

Outstanding! I had no idea that that was possible.
It shows how out of date I am.
How did you go about setting up Bochs?

No, the synergy has its limits.
In your yard there are two items: a bicycle (8080) and
a motorcycle (8086). Pick one. You want to motorize
your bicycle?? -- but you have a motorcycle already.

The byte codes of the two processors are different.
A RET is a RET but the byte code for each cpu are different.

The 8086 really is a step up in address capability from
the 8080.
The 8086 can mimic the 8080 addressing map by setting CS=DS=SS,
but it offers more. The addressing mapping can offer more; a
CS of 64k, a DS of 64k, a SS of 64k, for larger programs than
those on an 8080.

The addressing modes are different. With segmentation, many modes
of addressing are designed into the 8086 address decoding. The
8080 has one mode. (tiny model).

> > Although alot of programming wizardry was done in 61k the
> > future of 'bigger data' space was going to swap the 8080
> > abilities.
> Sure. There is no question of following the path
> from 8 bit to 64 bit.
>
> Some people dispute introducing segmentation as
> a somewhat temporary road along that path, but
> I'm not one of them.
> > The 'variable shift' concept totally escapes me.
> > Is it not possible that the cpu can already accomplish it, in other terms?
> > At the end of the day, the addressing modes resolve to a linear address.
> The 80286/80386 can accomplish the equivalent of a
> variable shift, if you line up the selectors, and
> you prepare for this in your programming, including
> the OS.
>
> And I intend to do this too.
>
> But the 80286 is much more difficult to produce than
> a modified 8086 that does 5-bit shifts. I don't want
> to rule that out either. And to me that is a very
> logical/clean thing to do regardless. Unless you can
> prove via maths that 4 has some magical power. Even

As a sidebar--
We are dealing in binary machines.
4 is one of those 'power of 2' numbers.
{1,2,4,8,16,32,...}
Their special property is that their value in binary is
of 1 bit set and the other bits cleared.
I'll stop there.

I'm beginning to get a mental picture of what you want, I think:
You require a 2mb addressing range, that is a 21 bits of addressing.
So, the 'shift 5' sets up the upper-most 16 address lines --
bits {21..5} and the lower-most 16 address lines {15..0}.
You want this 8086+ versus moving up to, say 32-bits, a 486 in
protected mode, because of the complexity of the hardware and software.
Because a dystopian senario won't support that level of technology.

I went back to the 486 manual.
Chapter 22 : Real Address Mode

22.1 Address Translation.

...
"
Because of the possibility of a carry, the resulting linear address
may have as many as 21 significant bits. An 8086 program may
generate linear addresses anywhere in the range of 0 to 10FFEFh
(1 megabyte plus approximately 64k) of the linear address space.
Because paging is not available in real-address mode, the linear
address is used as the physical address.
"
[Deducing from the above, an 8086 which does not have an A20 address line,
the value in CF is used instead in address translation exceeding 20 bits.]

The basic thrust of 32 bit programming re an 80486 OS is:
8086 support is present to setup the structures needed for protected mode,
and real mode code to effect the transfer into protected mode code and data.

> if someone produces an 8086 that has 4 hardcoded,
> zero chance of changing it, which indeed is exactly
> the case in real life, that's no reason for the
> software, including the OS, to treat the number 4
> as holy writ.
>
> Even though no-one did, there was never any barrier
> to someone producing an 8086-5 that did 5-bit shifts.
>
> And with FPGA, maybe the "no-one did" will change.
> Even if it is just for fun. And with Bochs or
> equivalent it becomes even more possible.
> > > I don't even properly understand the
> > > current state we are in, nor do I
> > > know if that was necessary.
>
> > A 1949 frame of view, ah but we're some seven decades past that..
> I'm not sure where we are, or even who "we" is.
>

"we" is humanity.
"where" is on the brink.

Steve

[Scott Lurndal]

"s_dub...@yahoo.com" <s_dub...@yahoo.com> writes:
>On Friday, September 30, 2022 at 8:12:09 PM UTC-5, muta...@gmail.com wrote:
>> On Thursday, September 29, 2022 at 1:13:56 AM UTC+8, s_dub...@yahoo.com wrote:
>>

>> > Computer scientists wanted separate Code and Data, CS & DS, as mentioned before.

Did they? Can you provide a cite? There have been certainly experiments
with "Harvard Architectures" over the decades, and while they still exist in
some embedded processors and digital signal processors (DSPs), they're not
common at all in general purpose computing, and weren't particularly common
in early mini- and main-frame computers.

Programmers today generally favor von neumann architectures where code and
data are in the same memory bank and use the same bus structures. CS/DS
simply segregate the main storage array to allow 128KB for Code and Data,
something that modern paging subsystems make far more useful and convenient.

As Steve pointed out, one can simply set CS=DS to share the code and data
in a single segment.

>> There's no sensible alternative for the segmentation
>> model, is there?
>
>Long mode with paging??

Indeed. A flat 64-bit address space is very useful and doesn't
carry any of the segmentation baggage from 1960's/1970's
state of the art segmented systems.

Note that ARM, PowerPC, MIPS (leaving aside KSEG0/1), SPARC and
ALPHA all support full flat address spaces (with paging).

>As a sidebar--
>We are dealing in binary machines.
>4 is one of those 'power of 2' numbers.
>{1,2,4,8,16,32,...}
>Their special property is that their value in binary is
>of 1 bit set and the other bits cleared.

AKA one-hot encoding.

[muta...@gmail.com]

On Wednesday, October 5, 2022 at 1:31:00 AM UTC+8, s_dub...@yahoo.com wrote:

> > No, I do not wish to be involved on the hardware side,
> > except for some basic questions like what's the extra
> > cost of the 8086 if variable shifts are added? Which
> > has already been answered, which is 5%.
> >
> > It is the software side I am interested in.

> You say that, yet all this talk of changing microprocessor functionality for
> 'variable shift' -and other things.

Yes, that is the interface between the hardware and
software. As a software person, I should be able to tell
the hardware engineers what I would like. I already
know that it is possible for minor cost.

> Please change your nomenclature in regards to 'shift 5'.
> It is confusing and irksome to assembly programmers who know that there are
> bit shifting instructions for doing shifting of values in registers and memory.
> You are discussing changing how address decoding should optionally work
> regarding segment registers in real mode address decoding.

5-bit, or variable segment shifts, seems clear to me.
But I'm happy to switch to your terminology. Which
is what? Hopefully not copy and paste the above
paragraph every time?

> When I said segment register value is translated 'AS IF' the segment value is
> shifted left 4 bits and the IP offset is added to it for the purpose of
> address translation to a linear address, I didn't mean that shift 4 is some
> sort of variable, or available to be changed, just to be clear.

I want it to be variable and available to be changed.
It's unclear to me where though. Perhaps the shift
can be set in the BIOS and then the BIOS executes
an 8086+ instruction to set the shift value.

Making a CPU with a hard-coded shift of 5 would be
a last resort.

> > > Computer scientists wanted separate Code and Data, CS & DS, as mentioned before.
> > There's no sensible alternative for the segmentation
> > model, is there?
> Long mode with paging??

Sorry for my sloppy English.

Once a decision is made to use segmentation
to exceed 64k, there is no real alternative to
what Intel did, is there?

> How did you go about setting up Bochs?

It is available from the Google Play store.

> > > A data register - DE DX
> > > A data register - BC CX
> > > So, there is some synergy there.
> > But can you answer the question - can that
> > synergy be total, so that the 8080-replacement
> > can be a subset of the 8086, or would both
> > processors need some adjustment?
> No, the synergy has its limits.
> In your yard there are two items: a bicycle (8080) and
> a motorcycle (8086). Pick one. You want to motorize
> your bicycle?? -- but you have a motorcycle already.

No, I want to remove the engine from the motorcycle,
but keep the frame.

> The byte codes of the two processors are different.
> A RET is a RET but the byte code for each cpu are different.

And why can't the 8080-replacement use the same
byte code as the 8086?

> The 8086 really is a step up in address capability from
> the 8080.
> The 8086 can mimic the 8080 addressing map by setting CS=DS=SS,
> but it offers more. The addressing mapping can offer more; a
> CS of 64k, a DS of 64k, a SS of 64k, for larger programs than
> those on an 8080.
>
> The addressing modes are different. With segmentation, many modes
> of addressing are designed into the 8086 address decoding. The
> 8080 has one mode. (tiny model).

Right, and what is preventing an 8086 tiny model program
from running on an 8080-replacement?

> I'm beginning to get a mental picture of what you want, I think:
> You require a 2mb addressing range, that is a 21 bits of addressing.
> So, the 'shift 5' sets up the upper-most 16 address lines --
> bits {21..5} and the lower-most 16 address lines {15..0}.

And then added together, correct.

> You want this 8086+ versus moving up to, say 32-bits, a 486 in
> protected mode, because of the complexity of the hardware and software.
> Because a dystopian senario won't support that level of technology.

Exactly.

And not just a dystopian scenario, but acknowledgement
that with the benefit of hindsight, this would have solved
real world problems with RM16, for basically no cost.

> Because of the possibility of a carry, the resulting linear address
> may have as many as 21 significant bits. An 8086 program may
> generate linear addresses anywhere in the range of 0 to 10FFEFh
> (1 megabyte plus approximately 64k) of the linear address space.
> Because paging is not available in real-address mode, the linear
> address is used as the physical address.
> "
> [Deducing from the above, an 8086 which does not have an A20 address line,
> the value in CF is used instead in address translation exceeding 20 bits.]

The carry flag is for the result of operations, completely
unrelated to addressing, as far as I'm aware.

BFN. Paul.

[Joe Monk]

"Right, and what is preventing an 8086 tiny model program
from running on an 8080-replacement? "

8086 is source compatible with 8080. That means an 8086 can run 8080 instructions - but the reverse is not true.

Joe

[muta...@gmail.com]

There was a translation program required to
convert 8080 source into 8086 source.

But even if that was not required, that
still doesn't answer my question.

I'm after an 8080 replacement that does a
SUBSET of 8086 tiny model instructions.

Is that possible, or is there a technical
issue in switching between 8 bit
and 16 bit such that the closest you
can get is source translation?

[wolfgang kern]

On 07/10/2022 22:42, muta...@gmail.com wrote:
> On Friday, October 7, 2022 at 6:48:02 PM UTC+8, Joe Monk wrote:
>> "Right, and what is preventing an 8086 tiny model program
>> from running on an 8080-replacement? "
>> 8086 is source compatible with 8080. That means an 8086 can run 8080 instructions - but the reverse is not true.
>
> There was a translation program required to
> convert 8080 source into 8086 source.

yeah, but only to improve performance

> But even if that was not required, that
> still doesn't answer my question.
>
> I'm after an 8080 replacement that does a
> SUBSET of 8086 tiny model instructions.
>
> Is that possible, or is there a technical
> issue in switching between 8 bit
> and 16 bit such that the closest you
> can get is source translation?

have you checked on 8085, Z80 and Z-280 ?
Z80 can do 8080 code but is different from 8086.
back then long ago I decided for ZILOG and built
my first mini-PCs with Z80 and NSC800 (1979...)

my favorite MC/CPU was Z-280 until 1985, after
this I started with purchased 286/AMD486..64 PCs.

But my production line on ZILOG based mini-PC run
until 1997 even I programmed a lot of x86 stuff :)

I skipped 80186, 80386 and all later Intel-crap
because I prefer AMD (currently on RyZen5).
__
wolfgang

[muta...@gmail.com]

On Saturday, October 8, 2022 at 1:57:22 PM UTC+8, wolfgang kern wrote:
> On 07/10/2022 22:42, muta...@gmail.com wrote:
> > On Friday, October 7, 2022 at 6:48:02 PM UTC+8, Joe Monk wrote:
> >> "Right, and what is preventing an 8086 tiny model program
> >> from running on an 8080-replacement? "
> >> 8086 is source compatible with 8080. That means an 8086 can run 8080 instructions - but the reverse is not true.
> >
> > There was a translation program required to
> > convert 8080 source into 8086 source.
> yeah, but only to improve performance

That suggests to me that if performance
is not an issue, then 8080 source code
can be compiled into 8086 instructions.

But I guess those 8086 instructions may be
different from the 8080 instructions.

Which is not what I am after.

Regarding z80 etc - if they could
have been produced in the 8080
timeframe for similar to 8080 cost,
that would be fine - so long as they are
compatible with a subset of 8086
tiny memory model.

[Joe Monk]

> > There was a translation program required to
> > convert 8080 source into 8086 source.
> yeah, but only to improve performance

> That suggests to me that if performance
> is not an issue, then 8080 source code
> can be compiled into 8086 instructions.
>

The "translator" is actually a cross-assembler that can read 8080A code.

http://www.bitsavers.org/pdf/intel/ISIS_II/9800642A_MCS-86_Assembly_Language_Converter_Operating_Instructions_for_ISIS-II_Users_Mar79.pdf

Joe

[muta...@gmail.com]

Thanks for the link, but I'm still totally lost.

The manual says:

This manual describes how the ISIS-II user who is familiar with 8080/8085 assembly

language can convert 8080/8085 source files to 8086 assembly language source files,
which can then be assembled, linked, located, and run to perform their equivalent
8080/8085 functions on the upwardly compatible, 16-bit 8086.


And later:
Recall that in going from the 8080 to
the 8086, both the instruction size (length) and time (clocks) change.


That doesn't sound like upwardly compatible to me.

But the fact that they mention instruction
lengths suggest to me that the
instructions do actually exist, but the
8080 took advantage of all 256 values
of the first byte for 8 bit instructions,
leaving no room for expansion to
add 16 bit instructions.

In which case, my question becomes -
at the time of the 8080, was there any
technical barrier to using the longer form
of the instructions?

Yes, it would have made the executable
bigger, and slower, but would the cost
be within 5%?

I guess that's not the nature of the beast
though. People would rather wring out every
ounce of performance of the current
processor and require programmers
to recompile for the next generation of
CPU.

Although that wasn't required going
from s390 to zarch.

Maybe processors were so fast by
zarch that it didn't matter if the zarch
instruction length wasn't optimized
for 64 bit.

Anyway, so a short:

Mov a, c

Becomes a longer instruction

Mov Al, cl

And in some sense, perhaps conceptually,
that is considered to be upwardly compatible.

The call 5 to terminate and other
services were probably reasonable too.

I suspect we just needed a commitment
to reserve the immediate area above
1 MB for a jump to c0 etc

For bioses that didn't have suitable jumps.

Perhaps something that could have been
done in preparation for the 8086
was to get people to code

Mov Al,cl

Even though there was no ah/ch yet.

Maybe someone could have had
an 8080-like processor with the
longer instructions, since when you
upgrade to 8086 your executable will
be restricted to 64k with long instructions anyway.

Maybe assembler source could have a

.8080

Which allows

Mov Al,cl

But not

Mov ah,ch

And maybe assemblers could
have an option to output short
8080 instructions or long 8086
instructions.

I can live with that.

Just so long as I know how to
write assembler that works on
both 8086 and 8080.

And the 8086 code works on x64 too.

And the code will be generated
by a c compiler too, possibly.

The generated op codes changed
a bit from 8086 to pm32 too, I think.

So it's the nature of x86 that you
need to reassemble at each step.

Unless you buy a processor that supports
different modes.

Could the call 5 have been replaced by
something similar to UEFI?

Because I would like the int calls replaced.

Maybe int is wrong but call 5 is fine.

Maybe there should be a single call
number, the equivalent of int 21h.

[Joe Monk]

> And later:
> Recall that in going from the 8080 to
> the 8086, both the instruction size (length) and time (clocks) change.
>
>
> That doesn't sound like upwardly compatible to me.
>

Yep. They are SOURCE upwardly compatible. Not Binary.

Joe

[s_dub...@yahoo.com]

On Tuesday, October 4, 2022 at 1:00:57 PM UTC-5, Scott Lurndal wrote:
> "s_dub...@yahoo.com" <s_dub...@yahoo.com> writes:
> >On Friday, September 30, 2022 at 8:12:09 PM UTC-5, muta...@gmail.com wrote:
> >> On Thursday, September 29, 2022 at 1:13:56 AM UTC+8, s_dub...@yahoo.com wrote:
> >>
>
> >> > Computer scientists wanted separate Code and Data, CS & DS, as mentioned before.
> Did they? Can you provide a cite? There have been certainly experiments
> with "Harvard Architectures" over the decades, and while they still exist in
> some embedded processors and digital signal processors (DSPs), they're not
> common at all in general purpose computing, and weren't particularly common
> in early mini- and main-frame computers.
>
> Programmers today generally favor von neumann architectures where code and
> data are in the same memory bank and use the same bus structures. CS/DS
> simply segregate the main storage array to allow 128KB for Code and Data,
> something that modern paging subsystems make far more useful and convenient.
>
> As Steve pointed out, one can simply set CS=DS to share the code and data
> in a single segment.

I did a cursory look for something I could cite, but didn't find anything close. mea culpa.
I'm thinking one might be found in the software security branch of the knowledge tree.

When we get to intel's 486 and it's protected mode, 32 bit, model, segment meta data
allows for more security. The meta data of descriptors does as much:
CS code can be set to Read Only to impede self-modifing coding.
DS data can be set to RO for static data, and RW for dynamic data variables, and the stack.
Additionally there's the protection level rings for a 'trusted code' model.

I'll stop here.

Steve

[s_dub...@yahoo.com]

On Tuesday, October 4, 2022 at 5:01:43 PM UTC-5, muta...@gmail.com wrote:
> On Wednesday, October 5, 2022 at 1:31:00 AM UTC+8, s_dub...@yahoo.com wrote:
>
> > > No, I do not wish to be involved on the hardware side,
> > > except for some basic questions like what's the extra
> > > cost of the 8086 if variable shifts are added? Which
> > > has already been answered, which is 5%.
> > >
> > > It is the software side I am interested in.
>
> > You say that, yet all this talk of changing microprocessor functionality for
> > 'variable shift' -and other things.
> Yes, that is the interface between the hardware and
> software. As a software person, I should be able to tell
> the hardware engineers what I would like. I already
> know that it is possible for minor cost.
> > Please change your nomenclature in regards to 'shift 5'.
> > It is confusing and irksome to assembly programmers who know that there are
> > bit shifting instructions for doing shifting of values in registers and memory.
> > You are discussing changing how address decoding should optionally work
> > regarding segment registers in real mode address decoding.
> 5-bit, or variable segment shifts, seems clear to me.
> But I'm happy to switch to your terminology. Which
> is what? Hopefully not copy and paste the above
> paragraph every time?

Well gee, 'segment shift-5' or something quoted, to alert the reader to a 'so-called' status.

> > When I said segment register value is translated 'AS IF' the segment value is
> > shifted left 4 bits and the IP offset is added to it for the purpose of
> > address translation to a linear address, I didn't mean that shift 4 is some
> > sort of variable, or available to be changed, just to be clear.
> I want it to be variable and available to be changed.
> It's unclear to me where though. Perhaps the shift
> can be set in the BIOS and then the BIOS executes
> an 8086+ instruction to set the shift value.
>

It would need to be, istm, an unique instruction for each of the 'shift' values in the
microcode of the processor.

I'm sounding out, "Be aware!" -- because I'm quoting the 486 manual.
The twenty-first significant bit is the CF.

Steve
>
> BFN. Paul.

[s_dub...@yahoo.com]

On Saturday, October 8, 2022 at 3:36:48 PM UTC-5, muta...@gmail.com wrote:
> On Saturday, October 8, 2022 at 8:14:03 PM UTC+8, Joe Monk wrote:
> > > > There was a translation program required to
> > > > convert 8080 source into 8086 source.
> > > yeah, but only to improve performance
> >
> > > That suggests to me that if performance
> > > is not an issue, then 8080 source code
> > > can be compiled into 8086 instructions.
> > >
> > The "translator" is actually a cross-assembler that can read 8080A code.
> >
> > http://www.bitsavers.org/pdf/intel/ISIS_II/9800642A_MCS-86_Assembly_Language_Converter_Operating_Instructions_for_ISIS-II_Users_Mar79.pdf
> Thanks for the link, but I'm still totally lost.
>
> The manual says:
>
> This manual describes how the ISIS-II user who is familiar with 8080/8085 assembly
>
> language can convert 8080/8085 source files to 8086 assembly language source files,
> which can then be assembled, linked, located, and run to perform their equivalent
> 8080/8085 functions on the upwardly compatible, 16-bit 8086.
>
>
> And later:
> Recall that in going from the 8080 to
> the 8086, both the instruction size (length) and time (clocks) change.
>
>
> That doesn't sound like upwardly compatible to me.
>

No it doesn't.
Thanks to Joe for the find!

> But the fact that they mention instruction
> lengths suggest to me that the
> instructions do actually exist, but the
> 8080 took advantage of all 256 values
> of the first byte for 8 bit instructions,
> leaving no room for expansion to
> add 16 bit instructions.
>
> In which case, my question becomes -
> at the time of the 8080, was there any
> technical barrier to using the longer form
> of the instructions?
>
> Yes, it would have made the executable
> bigger, and slower, but would the cost
> be within 5%?
>

Yes, lets talk about costs.
I forget the actual cost of RAM back then, north of $100 for only 4k.
(In 1970 $ that's about $400 in todays $, I think.)
Gates and crew got their start with a 4k BASIC
- not much room for app size after the interpreter size!
IOW, every byte counted.
The initial IBM PC was marketed with only 128k, and only socketed for 512k.
Which means, even if you could afford the memory, the top 128k couldn't
be installed (of the 640k address space).
Steve

[s_dub...@yahoo.com]

I was fond of the Amstrad PCW 8256 which had the Z80 and a
custom FPGA which managed 3 memory banks and ran CP/M-PLUS
aka CP/M-3 in banked mode.
The FPGA also managed a Hercules like video in monochrome graphics.
It also managed excess memory as a RAM drive.
Bank 0 held the ancillary system code and interface to the FPGA.
Bank 1 held the typical application memory.
Bank 2 had the memory mapped graphic image.

Steve

[muta...@gmail.com]

On Monday, October 10, 2022 at 1:59:54 AM UTC+8, s_dub...@yahoo.com wrote:

> > I want it to be variable and available to be changed.
> > It's unclear to me where though. Perhaps the shift
> > can be set in the BIOS and then the BIOS executes
> > an 8086+ instruction to set the shift value.
> >
> It would need to be, istm, an unique instruction for each of the 'shift' values in the
> microcode of the processor.

Why?

What's wrong with

SSS AL

Set segment shift to the value in AL
which must be 0 to 16.

And GSS AL to retrieve the value into AL

Front-ended by bios int 15h something
to set or get the value, allowing different
processors to implement it differently, or
like the real 8086, having the value 4
hardcoded.

And front-ended by an MSDOS call
int 21h something for use by applications.
And make the int 21h call more flexible to
allow an indicator to say what segmentation
scheme is in effect, e.g. pm16 rather than
say segment shift-7, with a routine
to call if you need to add a dx:ax to
a huge pointer.

[Kerr-Mudd, John]

On Sun, 9 Oct 2022 11:42:07 -0700 (PDT)
"s_dub...@yahoo.com" <s_dub...@yahoo.com> wrote:

[ re 8086 v 8080 ]

> Yes, lets talk about costs.
> I forget the actual cost of RAM back then, north of $100 for only 4k.
> (In 1970 $ that's about $400 in todays $, I think.)
> Gates and crew got their start with a 4k BASIC

I don't recall that, the IBM BASIC in ROM was 16k, IIRC
gosh it was "doable" n 4k it seems:
http://altairbasic.org/

> - not much room for app size after the interpreter size!
> IOW, every byte counted.
> The initial IBM PC was marketed with only 128k, and only socketed for 512k.
> Which means, even if you could afford the memory, the top 128k couldn't
> be installed (of the 640k address space).
> Steve
>

[]

--
Bah, and indeed Humbug.

[Joe Monk]

> I don't recall that, the IBM BASIC in ROM was 16k, IIRC
> gosh it was "doable" n 4k it seems:

"Altair BASIC was delivered on paper tape and in its original version took 4 KB of memory. "

https://en.wikipedia.org/wiki/Microsoft_BASIC#Altair_BASIC_and_early_microcomputers

Joe

[Joe Monk]

> SSS AL
>
> Set segment shift to the value in AL
> which must be 0 to 16.
>
> And GSS AL to retrieve the value into AL

The problem with variable shifted segments (and why they haven't been implemented) is that they lead to memory fragmentation.

Joe

[muta...@gmail.com]

Not sure what you're talking about.

This is a once-off instruction to be executed.

There is nothing magical about 4 bit
shifts that are totally memory efficient, zero
fragmentation, but 5 bits would be
totally horrendous, unacceptable to the
whole world without exception.

Personally I want 2 mb of memory
rather than 1 MB, and I'll wear the
slightly inferior fragmentation.

[Joe Monk]

> Not sure what you're talking about.
>
> This is a once-off instruction to be executed.
>

Says who? What will stop me from executing it any time I want?

> There is nothing magical about 4 bit
> shifts that are totally memory efficient, zero
> fragmentation, but 5 bits would be
> totally horrendous, unacceptable to the
> whole world without exception.
>

The 8086 has 20 address lines, but is a 16 bit architecture. 20-16 = 4.

To do a 16-bit shift = you'll need 32 address lines - 16. How much extra circuitry will that require?

> Personally I want 2 mb of memory
> rather than 1 MB, and I'll wear the
> slightly inferior fragmentation.

And how much are you going to pay? They would have to add the extra circuitry to the chip for the extra address lines, produce them, and what will be the production qty?

Joe

[Scott Lurndal]

[wolfgang kern]

On 10/10/2022 11:17, muta...@gmail.com wrote:
...

> This is a once-off instruction to be executed.
>
> There is nothing magical about 4 bit
> shifts that are totally memory efficient, zero
> fragmentation, but 5 bits would be
> totally horrendous, unacceptable to the
> whole world without exception.
>
> Personally I want 2 mb of memory
> rather than 1 MB, and I'll wear the
> slightly inferior fragmentation.

I once upgraded my Z80 based mini-PC boards
with a memory add-on to have 1MB static RAM
in mapped into the Z80's 64KB address range.
it needed one 8 bit I/O to add +4 address-lines
and 4 bits for variable gating 16 memory banks.

it turned out that one 64 KB block from the 1MB
wasn't accessible, but WTF: 1MB on Z80 worked.
__
wolfgang

[muta...@gmail.com]

Scott, you sent the above message with no
content that I can see.

[muta...@gmail.com]

On Monday, October 10, 2022 at 6:18:47 PM UTC+8, Joe Monk wrote:
> > Not sure what you're talking about.
> >
> > This is a once-off instruction to be executed.
> >
> Says who? What will stop me from executing it any time I want?

Nothing will stop you, but I doubt it will do
anything useful when the os has loaded all it's
content with a particular shift
value in effect and you choose
to switch it.

> > There is nothing magical about 4 bit
> > shifts that are totally memory efficient, zero
> > fragmentation, but 5 bits would be
> > totally horrendous, unacceptable to the
> > whole world without exception.
> >
> The 8086 has 20 address lines, but is a 16 bit architecture. 20-16 = 4.
>
> To do a 16-bit shift = you'll need 32 address lines - 16. How much extra circuitry will that require?

The instruction would refuse to change the shift
value on an 8086. On an 80286 it would only
need to support a shift value up
to 8.

Almost no extra circuitry would be required.

An 80386 should support a shift of 16.
Almost no extra circuitry would be required.

> > Personally I want 2 mb of memory
> > rather than 1 MB, and I'll wear the
> > slightly inferior fragmentation.
> And how much are you going to pay? They would have to add the extra circuitry to the chip for the extra address lines, produce them, and what will be the production qty?

The cost is close to nothing because there
are no extra address lines.