Getting started with Assembly language

[Vansh Kapoor]

I am trying to learn/understand assembly language for 80186 microprocessor. what would be the best source for that.

[Pete]

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186 microprocessor. what would be the best source for that.

Have you tried a Google search like this:

https://www.google.com/search?q=80186+assembly+language+tutorial

Peter

[David LaRue]

Post by Pete

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

https://www.google.com/search?q=80186+assembly+language+tutorial
Peter

For any computer look at the physical layout (registers, addressing, etc.)
and available commands. Now figure out how you or others would acomplish
various goals needed in the tasks you want to accomplish. Sources like
above can offer rules to follow, but perhaps the best way to learn is to do
it yourself and find ways to accomplish your goals. There may be many ways
to accomplish the same goal. Learn to adapt to various goals. Sample
goals could be instruction count, bytes needed for the assembly language,
and assembling your own building blocks for various projects.

[Peter Flass]

Post by David LaRue

Post by Pete

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

https://www.google.com/search?q=80186+assembly+language+tutorial
Peter

For any computer look at the physical layout (registers, addressing, etc.)
and available commands. Now figure out how you or others would acomplish
various goals needed in the tasks you want to accomplish. Sources like
above can offer rules to follow, but perhaps the best way to learn is to do
it yourself and find ways to accomplish your goals. There may be many ways
to accomplish the same goal. Learn to adapt to various goals. Sample
goals could be instruction count, bytes needed for the assembly language,
and assembling your own building blocks for various projects.

For any new language I usually like to start with a working sample program
and then play around and make changes to it to see what’s happening.

[Borax Man]

On Sat, 25 Nov 2023 10:30:16 -0700

Post by Peter Flass

Post by David LaRue

Post by Pete

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

https://www.google.com/search?q=80186+assembly+language+tutorial
Peter

For any computer look at the physical layout (registers, addressing, etc.)
and available commands. Now figure out how you or others would acomplish
various goals needed in the tasks you want to accomplish. Sources like
above can offer rules to follow, but perhaps the best way to learn is to do
it yourself and find ways to accomplish your goals. There may be many ways
to accomplish the same goal. Learn to adapt to various goals. Sample
goals could be instruction count, bytes needed for the assembly language,
and assembling your own building blocks for various projects.

For any new language I usually like to start with a working sample program
and then play around and make changes to it to see what’s happening.
--
Pete

Nothing beats having a good book. Unfortunately those targetting the
16 bit intel chips are old and hard to find. Jeff Duntemann's
Assembly Language Step-by-step is good, but current versions are
targetted towards Linux.

You can find a 1992 version here.

https://www.cin.ufpe.br/~clac/infra_de_software/Assembly%20Language%20Step%20by%20Step%201992.pdf

Another good resource is https://flatassembler.net/

There is an assembler, a forum, and the FASM Manual goes through the
intel instruction set in detail.


--

[Peter Flass]

Post by Borax Man
On Sat, 25 Nov 2023 10:30:16 -0700

Post by Peter Flass

Post by David LaRue

Post by Pete

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

https://www.google.com/search?q=80186+assembly+language+tutorial
Peter

For any computer look at the physical layout (registers, addressing, etc.)
and available commands. Now figure out how you or others would acomplish
various goals needed in the tasks you want to accomplish. Sources like
above can offer rules to follow, but perhaps the best way to learn is to do
it yourself and find ways to accomplish your goals. There may be many ways
to accomplish the same goal. Learn to adapt to various goals. Sample
goals could be instruction count, bytes needed for the assembly language,
and assembling your own building blocks for various projects.

For any new language I usually like to start with a working sample program
and then play around and make changes to it to see what’s happening.
--
Pete

Nothing beats having a good book. Unfortunately those targetting the
16 bit intel chips are old and hard to find. Jeff Duntemann's
Assembly Language Step-by-step is good, but current versions are
targetted towards Linux.

Is there anything else?

Post by Borax Man
You can find a 1992 version here.
https://www.cin.ufpe.br/~clac/infra_de_software/Assembly%20Language%20Step%20by%20Step%201992.pdf
Another good resource is https://flatassembler.net/
There is an assembler, a forum, and the FASM Manual goes through the
intel instruction set in detail.

[Vir Campestris]

Looking back through this thread - some advice from an old wrinkly
programmer.

My first assembler was a mainframe, back at the end of the 1970s - the
OS I was working on was entirely in assembler.

I learned 8085 assembler back when it was a hot new chip. I wrote lots.

The 8086 obviously came along, and I learned and used that a lot too.

The '286 was mostly just a faster 8086. Its protected mode was brain
damaged.

Come the '386, and even systems code wasn't using much in the way of
assembler. I don't think I did anything new except learn how the virtual
memory worked. That's been true of all the Intel chips since.

The last ten years or so I've been using ARM chips. I can just about
read the assembler, but I certainly wouldn't try to write it. Almost
everything is written in high level languages. Usually C or C++.

I'm sure compiler writers still need to know the assembler stuff, but
that's a small niche.

So, original poster - why do you think you need to learn assembler?
Especially for an obsolete chip?

Andy

[Bob Eager]

Post by Vir Campestris
Looking back through this thread - some advice from an old wrinkly
programmer.
My first assembler was a mainframe, back at the end of the 1970s - the
OS I was working on was entirely in assembler.
I learned 8085 assembler back when it was a hot new chip. I wrote lots.
The 8086 obviously came along, and I learned and used that a lot too.
The '286 was mostly just a faster 8086. Its protected mode was brain
damaged.
Come the '386, and even systems code wasn't using much in the way of
assembler. I don't think I did anything new except learn how the virtual
memory worked. That's been true of all the Intel chips since.

Worth mentioning more about the 80186. It incorporated a few extra
instructions, but nothing very major.

Principally, the reason for it was that it was a single chip solution (the
8086 required about 5 chips, as I recall). The 80186 incorporated the
interrupt controller, DMA controller, etc. It was however (at the OS
level) incompatible with the 8086.

The 8088 and 80188 had a similar relationship, with an 8 bit data bus.

The 80286 had completely incompatible memory management (but could operate
as a fast 8086). And there was also an 80288.

[Scott Lurndal]

Post by Bob Eager

Post by Vir Campestris
Looking back through this thread - some advice from an old wrinkly
programmer.
My first assembler was a mainframe, back at the end of the 1970s - the
OS I was working on was entirely in assembler.
I learned 8085 assembler back when it was a hot new chip. I wrote lots.
The 8086 obviously came along, and I learned and used that a lot too.
The '286 was mostly just a faster 8086. Its protected mode was brain
damaged.
Come the '386, and even systems code wasn't using much in the way of
assembler. I don't think I did anything new except learn how the virtual
memory worked. That's been true of all the Intel chips since.

Worth mentioning more about the 80186. It incorporated a few extra
instructions, but nothing very major.
Principally, the reason for it was that it was a single chip solution (the
8086 required about 5 chips, as I recall). The 80186 incorporated the
interrupt controller, DMA controller, etc. It was however (at the OS
level) incompatible with the 8086.

IME, the 80186 was primarily used as an embedded processor in
a larger system. We used them in the mainframe I/O subsystem.

[Juan]

Post by Bob Eager
Worth mentioning more about the 80186. It incorporated a few extra
instructions, but nothing very major.
Principally, the reason for it was that it was a single chip solution (the
8086 required about 5 chips, as I recall). The 80186 incorporated the
interrupt controller, DMA controller, etc. It was however (at the OS
level) incompatible with the 8086.

My first PC was a XT clone (Olivetti Prodest PC1), and it had a 80188
clone: the NEC V40.

According to the wikipedia, it integrated a compatible 8251 USART, 8253
PIT and 8255 PPI.

[Bob Eager]

Post by Juan

Post by Bob Eager
Worth mentioning more about the 80186. It incorporated a few extra
instructions, but nothing very major.
Principally, the reason for it was that it was a single chip solution
(the 8086 required about 5 chips, as I recall). The 80186 incorporated
the interrupt controller, DMA controller, etc. It was however (at the
OS level) incompatible with the 8086.

My first PC was a XT clone (Olivetti Prodest PC1), and it had a 80188
clone: the NEC V40.
According to the wikipedia, it integrated a compatible 8251 USART, 8253
PIT and 8255 PPI.

It also presumably had the barrel shifter from the V20/V30 8088/8086
equivalents, which improved multiply speed.

[Charlie Gibbs]

Post by Bob Eager

Post by Vir Campestris
Looking back through this thread - some advice from an old wrinkly
programmer.
My first assembler was a mainframe, back at the end of the 1970s - the
OS I was working on was entirely in assembler.
I learned 8085 assembler back when it was a hot new chip. I wrote lots.
The 8086 obviously came along, and I learned and used that a lot too.
The '286 was mostly just a faster 8086. Its protected mode was brain
damaged.
Come the '386, and even systems code wasn't using much in the way of
assembler. I don't think I did anything new except learn how the virtual
memory worked. That's been true of all the Intel chips since.

Worth mentioning more about the 80186. It incorporated a few extra
instructions, but nothing very major.
Principally, the reason for it was that it was a single chip solution (the
8086 required about 5 chips, as I recall). The 80186 incorporated the
interrupt controller, DMA controller, etc. It was however (at the OS
level) incompatible with the 8086.
The 8088 and 80188 had a similar relationship, with an 8 bit data bus.
The 80286 had completely incompatible memory management (but could operate
as a fast 8086). And there was also an 80288.

8080 One little,
8085 Two little,
8086 Three little-endians
8088 Four little,
80186 Five little,
80286 Six little-endians
80386 Seven little,
80386SX Eight little,
80486 Nine little-endians
Pentium DIVIDE ERROR

"I am Pentium of Borg. Division is futile. You will be approximated."

[Andy Walker]

Looking back through this thread - some advice from an old wrinkly programmer.
My first assembler was a mainframe, back at the end of the 1970s [...].

[History snipped.] I started with Atlas [apart from a brief go with
Edsac] in '66, and still have a shelf-full of snaffled m/c code, inc the O/S
[such as it was] and several compilers. On to KDF9, ICL 1900 and PDP 11 m/c
code. But after that, I didn't bother, and haven't missed it.

The last ten years or so I've been using ARM chips. I can just about
read the assembler, but I certainly wouldn't try to write it. Almost
everything is written in high level languages. Usually C or C++.

I more-or-less stopped using C [and never really started with C++]
30-odd years ago. Where practicable, I write shell scripts, using Sed and
other editors to do character twiddling; and Algol for serious computing.
I rarely even bother to compile the Algol; the interpreter is plenty fast
enough for anything short of full-scale astrophysical simulations [and is
hugely faster on my PC than the optimised compiled code on our university
mainframe in the 1970s].

I'm sure compiler writers still need to know the assembler stuff, but
that's a small niche.

Even most compiler writers can get away with "compiling" into C and
then relying on the work of others to get that into an executable! So the
niche is really /very/ small.

So, original poster - why do you think you need to learn assembler?
Especially for an obsolete chip?

To be fair, the OP didn't claim necessity. Anyone with an academic
bent is entitled simply to be curious about how things are, or were, done.
Personally, I hate not knowing things that interest me, and esp hate being
told that I don't /need/ to know them.

[Scott Lurndal]

Post by Andy Walker

Looking back through this thread - some advice from an old wrinkly programmer.
My first assembler was a mainframe, back at the end of the 1970s [...].

[History snipped.] I started with Atlas [apart from a brief go with
Edsac] in '66, and still have a shelf-full of snaffled m/c code, inc the O/S
[such as it was] and several compilers. On to KDF9, ICL 1900 and PDP 11 m/c
code. But after that, I didn't bother, and haven't missed it.

Have you considered donating that to one of the museums (such as CHM?)

m/c must be a British abbreviation for something...

Post by Andy Walker

The last ten years or so I've been using ARM chips. I can just about
read the assembler, but I certainly wouldn't try to write it. Almost
everything is written in high level languages. Usually C or C++.

I more-or-less stopped using C [and never really started with C++]
30-odd years ago. Where practicable, I write shell scripts, using Sed and
other editors to do character twiddling; and Algol for serious computing.
I rarely even bother to compile the Algol; the interpreter is plenty fast
enough for anything short of full-scale astrophysical simulations [and is
hugely faster on my PC than the optimised compiled code on our university
mainframe in the 1970s].

I'm sure compiler writers still need to know the assembler stuff, but
that's a small niche.

Even most compiler writers can get away with "compiling" into C and
then relying on the work of others to get that into an executable! So the
niche is really /very/ small.

The folks that must learn every nook and cranny of the machine language
are those who write processor simulators. I've done both ARMv7
and ARMv8 simulators over the last decade and thus have a quite
robust understanding of the instruction set and architecture. I have
no interest, for the most part, in writing code in assembler, however.

Post by Andy Walker

So, original poster - why do you think you need to learn assembler?
Especially for an obsolete chip?

To be fair, the OP didn't claim necessity. Anyone with an academic
bent is entitled simply to be curious about how things are, or were, done.
Personally, I hate not knowing things that interest me, and esp hate being
told that I don't /need/ to know them.

Understanding the machine language is often helpful when debugging
compiled code from higher-level languages.

[Andy Walker]

On 28/11/2023 16:15, Scott Lurndal wrote:
[I wrote:]

Post by Scott Lurndal

[...] I started with Atlas [apart from a brief go with
Edsac] in '66, and still have a shelf-full of snaffled m/c code, [...].

Have you considered donating that to one of the museums (such as CHM?)

Yes, but it's not in usable form and I have no great inclination to
spend my declining years writing it up. The offer of GBP 10^6 or so might
perhaps, but probably wouldn't, change my mind. The Computer Conservation
Society already has a copy of the Atlas O/S, I believe.

Atlas was a brilliant machine, with an innovative architecture and
machine code, but the assembler [ABL] was execrable [though ingenious]. You
had to learn all the numbers for instructions; very few symbolics.

Post by Scott Lurndal
m/c must be a British abbreviation for something...

Surely they have motor cycles in Left-Pondia? Not to be confused
with M/cr, which is Manchester; nor with mc, which is a hammer.

[Vir C:]

Post by Scott Lurndal

Post by Vir Campestris
I'm sure compiler writers still need to know the assembler stuff, but
that's a small niche.

Even most compiler writers can get away with "compiling" into C and
then relying on the work of others to get that into an executable! So the
niche is really /very/ small.

The folks that must learn every nook and cranny of the machine language
are those who write processor simulators.

That must be an even smaller niche!

[...]

Post by Scott Lurndal
Understanding the machine language is often helpful when debugging
compiled code from higher-level languages.

Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt with by
the compiler writers rather than by the "higher-level" program writers.

[Charlie Gibbs]

Post by Andy Walker

Post by Scott Lurndal
Understanding the machine language is often helpful when debugging
compiled code from higher-level languages.

Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt with by
the compiler writers rather than by the "higher-level" program writers.

Sometimes. On the other hand, if you have a compiler that's generating
bad code in a program that you need yesterday, you might have to change
your code to something equivalent which compiles successfully. BTDTGTS.

[John Dallman]

Post by Andy Walker
Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt
with by the compiler writers rather than by the "higher-level"
program writers.

Sometimes. On the other hand, if you have a compiler that's
generating bad code in a program that you need yesterday, you
might have to change your code to something equivalent which
compiles successfully. BTDTGTS.

And if you need to report compiler bugs, being able to point to exactly
what's wrong in the generated code means your bugs get fixed /much/
faster.

John

[Andy Walker]

[I wrote:]

Post by John Dallman

Post by Andy Walker
Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt
with by the compiler writers rather than by the "higher-level"
program writers.

Sometimes. On the other hand, if you have a compiler that's
generating bad code in a program that you need yesterday, you
might have to change your code to something equivalent which
compiles successfully. BTDTGTS.

Well, likewise. But [normally] that's a problem of re-writing
your program [and/or perhaps, eg, switching off aggressive optimisation]
rather than delving into the generated assembler. Anything else is even
more niche than the cases described earlier.

Post by John Dallman
And if you need to report compiler bugs, being able to point to exactly
what's wrong in the generated code means your bugs get fixed /much/
faster.

Yes, but since the 1980s the chances are that the "generated code"
is C or similar rather than assembler. That way, a swanky new language is
instantly available on every computer with a C compiler. Only those who
are responsible for writing that initial C compiler or for maintaining
[eg] Gcc need to know assembler. Apart, that is, from the few very niche
applications of the sort discussed earlier.

[Even in the 1970s, it was becoming common, eg in the Amsterdam
Compiler Kit, to compile to an intermediate level, such as P-code, rather
than direct to some form of assembler/machine code.]

IOW, the ordinary HLL programmer has no need at all to learn much
about the hardware the program is running on. That is, surely, the whole
point of a HLL. Being interested in the hardware is a different matter,
and I certainly wouldn't want to stop the OP from learning such things.

[Scott Lurndal]

Post by Andy Walker
[I wrote:]

Post by John Dallman

Post by Andy Walker
Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt
with by the compiler writers rather than by the "higher-level"
program writers.

Sometimes. On the other hand, if you have a compiler that's
generating bad code in a program that you need yesterday, you
might have to change your code to something equivalent which
compiles successfully. BTDTGTS.

Well, likewise. But [normally] that's a problem of re-writing
your program [and/or perhaps, eg, switching off aggressive optimisation]
rather than delving into the generated assembler. Anything else is even
more niche than the cases described earlier.

It's much quicker, particularly in a very large application, to
either debug post failure (e.g. SIGSEGV) with a good debugger
in which case knowing the assembler is useful, or to set a breakpoint
and step through the instruction sequence to see exactly what is
happening. I've done this many times over the last four decades
on systems from mainframes to microcontrollers. Most recently,
this morning to debug a SIGSEGV in a C++ application.

Post by Andy Walker

Post by John Dallman
And if you need to report compiler bugs, being able to point to exactly
what's wrong in the generated code means your bugs get fixed /much/
faster.

Yes, but since the 1980s the chances are that the "generated code"
is C or similar rather than assembler.

I absolutely disagree with this statement. I haven't used a compiler
that generates C since C++2.1/3.0 in the early 1990's. I'm not aware of
any modern compiler (from Ada to Python) that generates intermediate
C code.

And as someone who has extensive experience debugging cfront (the
original C++ compiler which generated C), the resulting C code
is completely unreadable and hardly useful for debugging application
code. I had to debug a register allocation issue with the underlying
C compiler used to compile the output from cfront once, and the
internal expression tree for the failed expression had five levels
with dozens of terms. The issue was that the C compiler (for the
motorola 88100, based on PCC) ran out of temporary registers when generating
code for the expression.

[Peter Flass]

Post by Scott Lurndal

Post by Andy Walker
[I wrote:]

Post by John Dallman

Post by Andy Walker
Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt
with by the compiler writers rather than by the "higher-level"
program writers.

Sometimes. On the other hand, if you have a compiler that's
generating bad code in a program that you need yesterday, you
might have to change your code to something equivalent which
compiles successfully. BTDTGTS.

Well, likewise. But [normally] that's a problem of re-writing
your program [and/or perhaps, eg, switching off aggressive optimisation]
rather than delving into the generated assembler. Anything else is even
more niche than the cases described earlier.

It's much quicker, particularly in a very large application, to
either debug post failure (e.g. SIGSEGV) with a good debugger
in which case knowing the assembler is useful, or to set a breakpoint
and step through the instruction sequence to see exactly what is
happening. I've done this many times over the last four decades
on systems from mainframes to microcontrollers. Most recently,
this morning to debug a SIGSEGV in a C++ application.

Some days I practically live in the debugger.

Post by Scott Lurndal

Post by Andy Walker

Post by John Dallman
And if you need to report compiler bugs, being able to point to exactly
what's wrong in the generated code means your bugs get fixed /much/
faster.

Yes, but since the 1980s the chances are that the "generated code"
is C or similar rather than assembler.

I absolutely disagree with this statement. I haven't used a compiler
that generates C since C++2.1/3.0 in the early 1990's. I'm not aware of
any modern compiler (from Ada to Python) that generates intermediate
C code.

I believe gcc has some type of fairly well-defined intermediate code. Some
compilers compile to this and use gcc’s back end to generate machine code.

Post by Scott Lurndal
And as someone who has extensive experience debugging cfront (the
original C++ compiler which generated C), the resulting C code
is completely unreadable and hardly useful for debugging application
code. I had to debug a register allocation issue with the underlying
C compiler used to compile the output from cfront once, and the
internal expression tree for the failed expression had five levels
with dozens of terms. The issue was that the C compiler (for the
motorola 88100, based on PCC) ran out of temporary registers when generating
code for the expression.

[Scott Lurndal]

Post by Peter Flass

Post by Scott Lurndal
I absolutely disagree with this statement. I haven't used a compiler
that generates C since C++2.1/3.0 in the early 1990's. I'm not aware of
any modern compiler (from Ada to Python) that generates intermediate
C code.

I believe gcc has some type of fairly well-defined intermediate code.

In a manner of speaking, yes. It's not something the user will ever
see or need to debug, however.

Post by Peter Flass
Some
compilers compile to this and use gcc’s back end to generate machine code.

LLVM is the poster child for this, although gcc has had a more primitive
form for a couple decades.

[Vir Campestris]

Post by Peter Flass
Some days I practically live in the debugger.

I retired last year. I could afford it, and my time isn't infinite.

There was no point in me learning about the future developments, so I
spent the last six months or so looking at the most common crashes in
the dumps our system collects from end users. (it's an embedded system
with a net connection) I often had to poke about in the assembly,
sometimes the optimiser does weird things.

BUT... if you're doing standard apps development I doubt you'll need to
do that often.

I was gratified that the last fix I ever submitted as a professional got
this comment from the guy who wrote the code: "Oh, THAT'S what's going
on" :)

Andy

[Bob Eager]

Post by Andy Walker
[Even in the 1970s, it was becoming common, eg in the Amsterdam
Compiler Kit, to compile to an intermediate level, such as P-code,
rather than direct to some form of assembler/machine code.]

In the mid 1960s, the BCPL compiler, and OCODE.

[John Dallman]

Post by Andy Walker

Post by John Dallman
And if you need to report compiler bugs, being able to point to
exactly what's wrong in the generated code means your bugs get fixed
/much/ faster.

Yes, but since the 1980s the chances are that the "generated code"
is C or similar rather than assembler. That way, a swanky new
language is instantly available on every computer with a C compiler.
Only those who are responsible for writing that initial C compiler
or for maintaining [eg] Gcc need to know assembler.

This is actually extremely rare. It is nonetheless the way I work, with a
domain-specific language that's an extended, type-secure C. It does many
things that C++ does not, so we keep on using it.

There are thus two levels at which I can report compiler bugs: in the DSL
and in the C compilers I'm using. In 28 years in the job, I've found,
reported, and got fixes for about two bugs in the DSL, and over a hundred
in assorted C compilers.

The C compiler bugs have ranged from subtle code generation bugs to
options the vendor told us to use but turned out not to exist. Turning
down optimisation is often a short-term fix, but Murphy's Law dictates
that some of the places where it is needed will be critical to
performance.

In the same way, tweaking the DSL's generation of C code lets us work
around some C compiler bugs, but the cost is usually performance.

Post by Andy Walker
IOW, the ordinary HLL programmer has no need at all to learn much
about the hardware the program is running on. That is, surely, the
whole point of a HLL.

Indeed. But if you want to produce high-quality software with high
performance on ordinary hardware and commonly-used operating systems, you
need someone who can dig out and report compiler bugs effectively.

John

[Scott Lurndal]

Post by John Dallman

Post by Andy Walker
Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt
with by the compiler writers rather than by the "higher-level"
program writers.

Sometimes. On the other hand, if you have a compiler that's
generating bad code in a program that you need yesterday, you
might have to change your code to something equivalent which
compiles successfully. BTDTGTS.

And if you need to report compiler bugs, being able to point to exactly
what's wrong in the generated code means your bugs get fixed /much/
faster.

And it may not even be a compiler bug, but a simple programming
error. Stepping through the generated assembler with a debugger
can be quite useful.

[Peter Flass]

Post by Scott Lurndal

Post by John Dallman

Post by Andy Walker
Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt
with by the compiler writers rather than by the "higher-level"
program writers.

Sometimes. On the other hand, if you have a compiler that's
generating bad code in a program that you need yesterday, you
might have to change your code to something equivalent which
compiles successfully.

And if you need to report compiler bugs, being able to point to exactly
what's wrong in the generated code means your bugs get fixed /much/
faster.

And it may not even be a compiler bug, but a simple programming
error. Stepping through the generated assembler with a debugger
can be quite useful.

Being a user of my own compiler is where it gets interesting. One of the
first things I learned was “don’t blame the compiler”, at least until
there’s no other possibility. Now I’ll blame the compiler first, and spend
quite a bit of time, only to find out it’s my own application error.

[John Dallman]

Post by Andy Walker
Yes, but how many programmers get to worry about such things? If
a compiler produces an executable that "doesn't work", it's dealt
with by the compiler writers rather than by the "higher-level"
program writers.

Sometimes. On the other hand, if you have a compiler that's
generating bad code in a program that you need yesterday, you
might have to change your code to something equivalent which
compiles successfully. BTDTGTS.

And if you need to report compiler bugs, being able to point to exactly
what's wrong in the generated code means your bugs get fixed /much/
faster.

John

[Vir Campestris]

Post by Andy Walker
[I wrote:]

Post by Scott Lurndal

[...] I started with Atlas [apart from a brief go with
Edsac] in '66, and still have a shelf-full of snaffled m/c code, [...].

Have you considered donating that to one of the museums (such as CHM?)

    Yes, but it's not in usable form and I have no great inclination to
spend my declining years writing it up.  The offer of GBP 10^6 or so might
perhaps, but probably wouldn't, change my mind.  The Computer Conservation
Society already has a copy of the Atlas O/S, I believe.
    Atlas was a brilliant machine, with an innovative architecture and
machine code, but the assembler [ABL] was execrable [though ingenious].
You
had to learn all the numbers for instructions;  very few symbolics.

Post by Scott Lurndal
m/c must be a British abbreviation for something...

    Surely they have motor cycles in Left-Pondia?  Not to be confused
with M/cr, which is Manchester;  nor with mc, which is a hammer.
[Vir C:]

It wasn't me that wrote m/c. But I have seen it used for machine. Not
recently though I think.

Post by Andy Walker

Post by Scott Lurndal

Post by Vir Campestris
I'm sure compiler writers still need to know the assembler stuff, but
that's a small niche.

    Even most compiler writers can get away with "compiling" into C and
then relying on the work of others to get that into an executable!
So the
niche is really /very/ small.

The folks that must learn every nook and cranny of the machine language
are those who write processor simulators.

    That must be an even smaller niche!
[...]

Post by Scott Lurndal
Understanding the machine language is often helpful when debugging
compiled code from higher-level languages.

    Yes, but how many programmers get to worry about such things?  If
a compiler produces an executable that "doesn't work", it's dealt with by
the compiler writers rather than by the "higher-level" program writers.

Debugging is why I learned ARM assembly at all. Just occasionally I bump
into some code that looks reasonable, but doesn't do what it should.
That's usually because of threading, but it can be because someone got
into the Undefined Behaviour corner of the language.

Andy

[Sn!pe]

Post by Vir Campestris

Post by Andy Walker
[I wrote:]

Post by Scott Lurndal

[...] I started with Atlas [apart from a brief go with
Edsac] in '66, and still have a shelf-full of snaffled m/c code, [...].

Have you considered donating that to one of the museums (such as CHM?)

Yes, but it's not in usable form and I have no great inclination to
spend my declining years writing it up. The offer of GBP 10^6 or so
might perhaps, but probably wouldn't, change my mind. The Computer
Conservation Society already has a copy of the Atlas O/S, I believe.
Atlas was a brilliant machine, with an innovative architecture and
machine code, but the assembler [ABL] was execrable [though ingenious].
You had to learn all the numbers for instructions; very few symbolics.

Post by Scott Lurndal
m/c must be a British abbreviation for something...

Surely they have motor cycles in Left-Pondia? Not to be confused
with M/cr, which is Manchester; nor with mc, which is a hammer.
[Vir C:]

It wasn't me that wrote m/c. But I have seen it used for machine. Not
recently though I think.

[...]

'm/c' for 'machine' was standard usage in the late '60s - early '70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

[Charlie Gibbs]

Post by Sn!pe
'm/c' for 'machine' was standard usage in the late '60s - early '70s;

In some circles, perhaps, but I never saw it.

Post by Sn!pe
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

I can see some bored etymologist digging into the origins of this
slash notation. It appears in several fields.

Can't fly today, the A/C is U/S.

[Peter Flass]

Post by Sn!pe

Post by Vir Campestris

Post by Andy Walker
[I wrote:]

Post by Scott Lurndal

[...] I started with Atlas [apart from a brief go with
Edsac] in '66, and still have a shelf-full of snaffled m/c code, [...].

Have you considered donating that to one of the museums (such as CHM?)

Yes, but it's not in usable form and I have no great inclination to
spend my declining years writing it up. The offer of GBP 10^6 or so
might perhaps, but probably wouldn't, change my mind. The Computer
Conservation Society already has a copy of the Atlas O/S, I believe.
Atlas was a brilliant machine, with an innovative architecture and
machine code, but the assembler [ABL] was execrable [though ingenious].
You had to learn all the numbers for instructions; very few symbolics.

Post by Scott Lurndal
m/c must be a British abbreviation for something...

Surely they have motor cycles in Left-Pondia? Not to be confused
with M/cr, which is Manchester; nor with mc, which is a hammer.
[Vir C:]

It wasn't me that wrote m/c. But I have seen it used for machine. Not
recently though I think.

[...]
'm/c' for 'machine' was standard usage in the late '60s - early '70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

Lemme guess - “tits up.”

[Ahem A Rivet's Shot]

On Wed, 29 Nov 2023 12:07:19 -0700

Post by Peter Flass

Post by Sn!pe
'm/c' for 'machine' was standard usage in the late '60s - early '70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

Lemme guess - “tits up.”

Of course - but then I thought m/c was well known too.

[Scott Lurndal]

Post by Ahem A Rivet's Shot
On Wed, 29 Nov 2023 12:07:19 -0700

Post by Sn!pe
'm/c' for 'machine' was standard usage in the late '60s - early '70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

Lemme guess - “tits up.”

Of course - but then I thought m/c was well known too.

T/U is rather obvious (it is two words, after all),
m/c less so, although machine was my first guess.

I've notice that some british english words are often
not phonetically related to the actual pronunciation
(e.g. lester square :-).

[Bob Eager]

Post by Ahem A Rivet's Shot

Post by Peter Flass

Post by Sn!pe
'm/c' for 'machine' was standard usage in the late '60s - early '70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

Lemme guess - “tits up.”

Of course - but then I thought m/c was well known too.

T/U is rather obvious (it is two words, after all), m/c less so,
although machine was my first guess.
I've notice that some british english words are often not phonetically
related to the actual pronunciation (e.g. lester square :-).

We have two villages near here, both named Goodnestone.

They have two totally different pronunciations. One is Good-nes-stone. The
other is Gun-stone.

[Bob Martin]

Post by Bob Eager

Post by Ahem A Rivet's Shot

Post by Peter Flass

Post by Sn!pe
'm/c' for 'machine' was standard usage in the late '60s - early '70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

Lemme guess - “tits up.”

Of course - but then I thought m/c was well known too.

T/U is rather obvious (it is two words, after all), m/c less so,
although machine was my first guess.
I've notice that some british english words are often not phonetically
related to the actual pronunciation (e.g. lester square :-).

We have two villages near here, both named Goodnestone.
They have two totally different pronunciations. One is Good-nes-stone. The
other is Gun-stone.

Same thing round here, with Bosham (pronounced Bozz'm) and Cosham (Cosh'm)

(Bosham is where King Canute had a palace).

[John Levine]

Post by Sn!pe

Post by Vir Campestris
It wasn't me that wrote m/c. But I have seen it used for machine. Not
recently though I think.

[...]
'm/c' for 'machine' was standard usage in the late '60s - early '70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

Lemme guess - “tits up.”

Temporarily Unavailable, of course. What else would it stand for?

[Sn!pe]

Post by John Levine

Post by Sn!pe

Post by Vir Campestris
It wasn't me that wrote m/c. But I have seen it used for machine. Not
recently though I think.

[...]
'm/c' for 'machine' was standard usage in the late '60s - early '70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

Lemme guess - ╲tits up.╡

Temporarily Unavailable, of course. What else would it stand for?

≈:o)

[John Dallman]

Post by Scott Lurndal
m/c must be a British abbreviation for something...

Machine. It's still used for that in the folded source code format I work
with, which was created in about 1985.

There used to be a form of abbreviation over here that used slashes a lot.
WWII-era examples included "w/t" for wireless telegraphy (Morse code over
radio) and "r/t" for radio-telephone (walkie-talkie).

John

[Lars Poulsen]

Post by Vir Campestris
The '286 was mostly just a faster 8086. Its protected mode was brain
damaged.

I used 80286 protected mode in an embedded project, and it was pretty
wonderful. Our code was written in C, and we used a compiler that mated
well with a "DOS Extender" to get beyond the 1MB limitations of the
basic 8086 model. We hacked the "malloc()" to give us a new segment for
each data structure, which gave us hardware bounds checking, which in
turn gave us greatly accellerated debugging.

I always felt that the Linux model of just a flat 32-bit address space
was a big step backwards.

286 protected mode was not a full memory management system for a paging
multiuser OS, but there was a use case where it worked VERY well.

[John Levine]

Post by Lars Poulsen

Post by Vir Campestris
The '286 was mostly just a faster 8086. Its protected mode was brain
damaged.

I used 80286 protected mode in an embedded project, and it was pretty
wonderful. Our code was written in C, and we used a compiler that mated
well with a "DOS Extender" to get beyond the 1MB limitations of the
basic 8086 model. We hacked the "malloc()" to give us a new segment for
each data structure, which gave us hardware bounds checking, which in
turn gave us greatly accellerated debugging.

There were two problems with 286 protected mode. One was that anything
that loaded a segment register was extremely slow, and the other was
that if you had any data structures bigger than 64K, you lose. Intel
went out of their way to make it miserable to use several segments for
one object by using three lowest bits of the segment number for status
stuff so consecutive segments would be 0, 8, 16 or maybe 3, 11, 19.

If you were willing to take the segment load performance hit and your
data all fit in 64K chunks, protected mode was fine.

The 386 mostly fixed the segment size problem but not the slow loads,
but by then nobody cared.

[Scott Lurndal]

Post by Lars Poulsen

Post by Vir Campestris
The '286 was mostly just a faster 8086. Its protected mode was brain
damaged.

I used 80286 protected mode in an embedded project, and it was pretty
wonderful. Our code was written in C, and we used a compiler that mated
well with a "DOS Extender" to get beyond the 1MB limitations of the
basic 8086 model. We hacked the "malloc()" to give us a new segment for
each data structure, which gave us hardware bounds checking, which in
turn gave us greatly accellerated debugging.
I always felt that the Linux model of just a flat 32-bit address space
was a big step backwards

That flat model, of course, predates linux by decades. Linus chose it
because it made sense. Segmented schemes have all been found
lacking.

[John Levine]

Post by Scott Lurndal

Post by Lars Poulsen
I always felt that the Linux model of just a flat 32-bit address space
was a big step backwards

That flat model, of course, predates linux by decades. Linus chose it
because it made sense. Segmented schemes have all been found
lacking.

Not really. Programmers loved the Burroughs mainframes with segmented
memory and a stack. They live on as Unisys Clearpath although Unisys
gave up building CPUs and now just runs an emulator on an x86. And
there are still plenty of people who say Multics was the best system
they ever used.

Architectures of any kind die for two reasons: they run out of address
bits, the vandor can't make them competitively fast, or both. As I
said a few messages back, the 286 suffered from both of those, loading
the segment registers was very slow, and the 64K segments were too
small.

A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then
the important software was written in machine-specific assembler,
while now it's all in C or other languages which don't really care
about the underlying instruction set, although C and its decendants
have assumptions about byte addressed flat memory baked deep into them.

If we'd ended up using something like Pascal or PL/I with stronger
pointer typing, segmented machines would still be plausible.

Oh, and Linux chose flat addressing because linux is a copy of Unix
and Unix grew up on Vaxes with flat memory. It made sense only in that
it made sense to copy the memory model along with everything else.

[Ahem A Rivet's Shot]

On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)

Post by John Levine
A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then
the important software was written in machine-specific assembler,
while now it's all in C or other languages which don't really care
about the underlying instruction set, although C and its decendants
have assumptions about byte addressed flat memory baked deep into them.

C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

[Charlie Gibbs]

Post by Ahem A Rivet's Shot
On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)

Post by John Levine
A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then
the important software was written in machine-specific assembler,
while now it's all in C or other languages which don't really care
about the underlying instruction set, although C and its decendants
have assumptions about byte addressed flat memory baked deep into them.

C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

In other words, a nightmare that continued from the mess that started
on the 8086/8. I shudder when I remember the hoops I had to jump
through when writing MS-DOS programs that accessed tables bigger
than 64K. Segment wrap-around, far pointer normalization to work
around it... blech!

[Ahem A Rivet's Shot]

On Wed, 13 Dec 2023 17:25:19 GMT

Post by Charlie Gibbs

Post by Ahem A Rivet's Shot
C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

In other words, a nightmare that continued from the mess that started
on the 8086/8.

Yep with added hardware protection.

[Peter Flass]

Post by Ahem A Rivet's Shot
On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)

Post by John Levine
A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then
the important software was written in machine-specific assembler,
while now it's all in C or other languages which don't really care
about the underlying instruction set, although C and its decendants
have assumptions about byte addressed flat memory baked deep into them.

C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

When I first started looking at the architecture, I thought all the memory
models were just nuts.

[Charlie Gibbs]

Post by Peter Flass

Post by Ahem A Rivet's Shot
On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)

Post by John Levine
A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then
the important software was written in machine-specific assembler,
while now it's all in C or other languages which don't really care
about the underlying instruction set, although C and its decendants
have assumptions about byte addressed flat memory baked deep into them.

C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

When I first started looking at the architecture, I thought all the memory
models were just nuts.

Yeah, too bad the Motorola 68000 arrived just a bit too late.

[John Levine]

Post by Charlie Gibbs

Post by Peter Flass

Post by Ahem A Rivet's Shot
C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

Yup, that's a consequence of the segments being too slow and too
small. On a more sensible segmented archiecture you could
put every allocated chunk of storage in a segment and the static
stuff in another segment so it's all be handled by the compiler.

Post by Charlie Gibbs

Post by Peter Flass
When I first started looking at the architecture, I thought all the memory
models were just nuts.

Yeah, too bad the Motorola 68000 arrived just a bit too late.

The 68000 was there. But when IBM was designing the IBM PC and they
decided at the last minute to move to a 16 bit chip while keeping the
8 bit memory and peripherals, the 8088 was available in quantity but
the 68008 was just samples. So here we are.

[Charlie Gibbs]

Post by John Levine

Post by Charlie Gibbs

Post by Peter Flass

Post by Ahem A Rivet's Shot
C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

Yup, that's a consequence of the segments being too slow and too
small. On a more sensible segmented archiecture you could
put every allocated chunk of storage in a segment and the static
stuff in another segment so it's all be handled by the compiler.

Post by Charlie Gibbs

Post by Peter Flass
When I first started looking at the architecture, I thought all the memory
models were just nuts.

Yeah, too bad the Motorola 68000 arrived just a bit too late.

The 68000 was there. But when IBM was designing the IBM PC and they
decided at the last minute to move to a 16 bit chip while keeping the
8 bit memory and peripherals, the 8088 was available in quantity but
the 68008 was just samples. So here we are.

You're right, I should have said 68008.

Someone once said, "Isn't it fortunate that the iAPX432 flopped?
Otherwise some horrible Intel architecture might have taken over
the world."

[Bob Martin]

Post by Charlie Gibbs

Post by Peter Flass

Post by Ahem A Rivet's Shot
On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)

Post by John Levine
A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then
the important software was written in machine-specific assembler,
while now it's all in C or other languages which don't really care
about the underlying instruction set, although C and its decendants
have assumptions about byte addressed flat memory baked deep into them.

C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

When I first started looking at the architecture, I thought all the memory
models were just nuts.

Yeah, too bad the Motorola 68000 arrived just a bit too late.

I liked the Texas 9900 instruction set.

[Bob Eager]

Post by Bob Martin

Post by Charlie Gibbs

Post by Peter Flass

Post by Ahem A Rivet's Shot
On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)

Post by John Levine
A big difference between the computing world now and back in the
1960s and 1870s when people were designing segmented machines is
that then the important software was written in machine-specific
assembler, while now it's all in C or other languages which don't
really care about the underlying instruction set, although C and its
decendants have assumptions about byte addressed flat memory baked
deep into them.

C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

When I first started looking at the architecture, I thought all the
memory models were just nuts.

Yeah, too bad the Motorola 68000 arrived just a bit too late.

I liked the Texas 9900 instruction set.

My favourite is the ICL 2900 instruction set - loosely based on the
Manchester MU5. Great for compiler writers.

http://www.ancientgeek.org.uk/ICL/The_ICL_2900_Series.pdf

[Vir Campestris]

Post by Bob Eager
My favourite is the ICL 2900 instruction set - loosely based on the
Manchester MU5. Great for compiler writers.

That's the first machine I used professionally. I quite liked the
DECsystem10 we had at Uni.

I went from the 2900 to an Intel 8085. Yuck. I spent quite a lot of my
career with 8085/8086/286 (yes, occasionally in protected mode), 386...
- and I never liked any of them.

More recently I used ARM chips, and TBH I don't really know what they
are like. I never needed to, they are fast enough without needing assembler.

Andy

[Bob Eager]

Post by Vir Campestris

Post by Bob Eager
My favourite is the ICL 2900 instruction set - loosely based on the
Manchester MU5. Great for compiler writers.

That's the first machine I used professionally. I quite liked the
DECsystem10 we had at Uni.

I used a PDP-10 (it was an old KA-10, and was never known as a
DECsystem-10) for a year. Hoping to build a replica soon.

Post by Vir Campestris
I went from the 2900 to an Intel 8085. Yuck. I spent quite a lot of my
career with 8085/8086/286 (yes, occasionally in protected mode), 386...
- and I never liked any of them.

My next was a Z80, then VAX, then 8086. I'd done PDP-11 long before.

Post by Vir Campestris
More recently I used ARM chips, and TBH I don't really know what they
are like. I never needed to, they are fast enough without needing assembler.

I only really looked at instruction sets in the context of writing
compilers.

[Ahem A Rivet's Shot]

On 15 Dec 2023 07:22:33 GMT

Post by Bob Martin
I liked the Texas 9900 instruction set.

Yes it was nice - the chip itself somewhat less so.

There was a 9900 based machine being built by a fellow student when
I was at college. The board was built, the wiring tested, all the other
components were in their sockets the time had come to put that 0.9" wide
sixty four pin ceramic packaged processor into its socket - many members of
the university processor group (student club) were present to watch ...

It really did not want to go in - not because the legs were splayed,
it was a ceramic package with straight legs. Instead it provided an object
lesson in the meaning of the term insertion force. In the end padded
support went under the board while the precious processor was tapped into
its socket with the aid of a small rubber mallet.

I stopped wanting to build one.

[Scott Lurndal]

Post by Bob Martin

Post by Charlie Gibbs

Post by Peter Flass

Post by Ahem A Rivet's Shot
On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)

Post by John Levine
A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then
the important software was written in machine-specific assembler,
while now it's all in C or other languages which don't really care
about the underlying instruction set, although C and its decendants
have assumptions about byte addressed flat memory baked deep into them.

C for the 286 was a horror story with multiple memory models and
near and far pointers exposed in the source code.

When I first started looking at the architecture, I thought all the memory
models were just nuts.

Yeah, too bad the Motorola 68000 arrived just a bit too late.

I liked the Texas 9900 instruction set.

The Burroughs medium systems instruction set was a joy to
work with. It was BCD, so one never needed to convert
between decimal and hex, or decimal and octal.

The instruction set basically mapped 1-1 to COBOL verbs.

COMPUTE HQ1 = (B - 1) / 14 + 1. 526 CARD 1 65428
01 065428 MVN 11A103 100000 100336 CODE
01 065446 MVN 110303 217556 100340 CODE
01 065464 DEC 030303 100336 100340 CODE
01 065482 MVN 110306 100340 100344 CODE
01 065500 MVN 11A115 000000 000351 CODE
01 065518 MVN 11A119 000000 100366 CODE
01 065536 DIV 06A221 140000 100344 100366 CODE
01 065560 MVN 11A105 100000 100386 CODE
01 065578 MVN 11A115 000000 000392 CODE
01 065596 INC 011920 100366 100386 CODE
01 065614 MVN 110101 000391 217452 CODE

INSPECT COURSE-B REPLACING ALL " " BY ZEROS. 531 CARD 1 65864
01 065864 MVN 110607 000774 100008 CODE
01 065882 SEA 39B101 400000 600000 050384 CODE
01 065906 NEQ 25 0C065962 CODE
01 065916 MVA 10A202 F0F0F0 400000 CODE
01 065934 INC 01A107 200000 100008 CODE
01 065952 BUN 27 0C065882 CODE

[Scott Lurndal]

Post by John Levine

Post by Scott Lurndal

Post by Lars Poulsen
I always felt that the Linux model of just a flat 32-bit address space
was a big step backwards

That flat model, of course, predates linux by decades. Linus chose it
because it made sense. Segmented schemes have all been found
lacking.

Not really. Programmers loved the Burroughs mainframes with segmented
memory and a stack. They live on as Unisys Clearpath although Unisys
gave up building CPUs and now just runs an emulator on an x86. And
there are still plenty of people who say Multics was the best system
they ever used.

Speaking as a Burroughs programmer who wrote portions of the MCP, I can't
agree with that. Our segmentation scheme was there simply
for backward compatability in the medium systems line.

The large systems version lives on in Clearpath Libra for
backward compatability with applications built in the 1960s.

There have been no new designs with segmentation for decades
and the effort to enhance the large systems
architecture and maintain compatability when E-mode was
added wasn't a simple exercise.

Post by John Levine
Architectures of any kind die for two reasons: they run out of address
bits, the vandor can't make them competitively fast, or both. As I
said a few messages back, the 286 suffered from both of those, loading
the segment registers was very slow, and the 64K segments were too
small.
A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then

Who was designing memory subsystems in the 1870s? :-)

Post by John Levine
If we'd ended up using something like Pascal or PL/I with stronger
pointer typing, segmented machines would still be plausible.

No, they have all the shortcomings of segmentation (limiting
data structure size and physical memory checkerboarding when
not combined with some form of paging within the segment).

Post by John Levine
Oh, and Linux chose flat addressing because linux is a copy of Unix
and Unix grew up on Vaxes with flat memory. It made sense only in that
it made sense to copy the memory model along with everything else.

Unix grew up on the PDP-11 with fixed segment sizes.

[Charlie Gibbs]

Post by Scott Lurndal

Post by John Levine
A big difference between the computing world now and back in the 1960s
and 1870s when people were designing segmented machines is that then

Who was designing memory subsystems in the 1870s? :-)

Charles Babbage?

[John Levine]

Post by Scott Lurndal
Speaking as a Burroughs programmer who wrote portions of the MCP, I can't
agree with that. Our segmentation scheme was there simply
for backward compatability in the medium systems line.
The large systems version lives on in Clearpath Libra for
backward compatability with applications built in the 1960s.
There have been no new designs with segmentation for decades
and the effort to enhance the large systems
architecture and maintain compatability when E-mode was
added wasn't a simple exercise.

I can believe it, but how much of that was because the segments were
too small? My impression is that's what killed all the segmented
architectures, and by the time you came up with a segment scheme with
bigger addresses, you might as well just adopt a generic flat address
and use all the free software that supports it.

Post by Scott Lurndal

Post by John Levine
Oh, and Linux chose flat addressing because linux is a copy of Unix
and Unix grew up on Vaxes with flat memory. It made sense only in that
it made sense to copy the memory model along with everything else.

Unix grew up on the PDP-11 with fixed segment sizes.

I was there and not really. On the 11/45 and 11/70 you got 64K of
instruction space and 64K of data space. The hardware divided each
into eight 8K pages but they were too big to be useful so each segment
was always contiguous and could be from 8K to 64K in 8K increments.
When Berkeley moved BSD to the Vax we all moved there and didn't look
back. (I was the first person to try running BSD on an 11/750 which
was painful because it had a micrcode bug that made an instruction in
the inner loop of printf() fail. I had just finished getting a hosted
cross-building environment going on our 11/45 at Yale when Bill Joy
noticed the same thing at Berkeley, patched around the instruction and
rebuilt it on his 11/780 so that's what we used.)

The Vax's paging enabled shared libraries and mapped files and
much larger programs on 4BSD. That's where all modern Unix
and linux trace back to, even though some of them do so
by merging the good bits of BSD into other varieties like
System V.

[Scott Lurndal]

Post by John Levine

Post by Scott Lurndal
Speaking as a Burroughs programmer who wrote portions of the MCP, I can't
agree with that. Our segmentation scheme was there simply
for backward compatability in the medium systems line.
The large systems version lives on in Clearpath Libra for
backward compatability with applications built in the 1960s.
There have been no new designs with segmentation for decades
and the effort to enhance the large systems
architecture and maintain compatability when E-mode was
added wasn't a simple exercise.

I can believe it, but how much of that was because the segments were
too small? My impression is that's what killed all the segmented
architectures, and by the time you came up with a segment scheme with
bigger addresses, you might as well just adopt a generic flat address
and use all the free software that supports it.

Certainly segment _size_ was an important constraint. Before we
revamped the medium systems architecture, a task/job/process was
limited to 500 kilobytes of memory (1 million digits). The
segmentation scheme that we added, for backward compatability,
couldn't support more than a million digits without significant
changes to the instruction set (which had 6-digit address operands);
so segmentation was the only way to maintain backward compatability
and preserve the ability to execute 1965 binaries without performance
killing emulation.

Adding paging within a segment, to ameliorate the pain of memory
fragmentation wasn't really possible at the time.

Post by John Levine

Post by Scott Lurndal

Post by John Levine
Oh, and Linux chose flat addressing because linux is a copy of Unix
and Unix grew up on Vaxes with flat memory. It made sense only in that
it made sense to copy the memory model along with everything else.

Unix grew up on the PDP-11 with fixed segment sizes.

I was there and not really. On the 11/45 and 11/70 you got 64K of

I was there using v6 on an 11/34. Granted, never had a chance
to use the 11/70, but heavily used the 11/780 (loved it!). Our
11/44 ran custom software acting as a terminal controller.

Post by John Levine
instruction space and 64K of data space. The hardware divided each
into eight 8K pages but they were too big to be useful so each segment
was always contiguous and could be from 8K to 64K in 8K increments.
When Berkeley moved BSD to the Vax we all moved there and didn't look
back.

I played a bit with the 32-bit WE Unix on the /780 on weekends, but we
always ran VMS in production. The earliest versions of VMS
we were using still used some RSX-11 utilities running in
compatability mode. Never used BSD.

Post by John Levine
The Vax's paging enabled shared libraries and mapped files and
much larger programs on 4BSD. That's where all modern Unix
and linux trace back to, even though some of them do so
by merging the good bits of BSD into other varieties like
System V.

We were working with AT&T/USL during the SVR4 development
when the BSD stuff was merged in. A large part of that was
user-level stuff, but it also included job-control and
iirc resource limit controls in the kernel itself.

[John Levine]

Post by Scott Lurndal

Post by John Levine
I was there and not really. On the 11/45 and 11/70 you got 64K of

I was there using v6 on an 11/34. Granted, never had a chance
to use the 11/70, but heavily used the 11/780 (loved it!). Our
11/44 ran custom software acting as a terminal controller.

Post by John Levine
instruction space and 64K of data space. The hardware divided each
into eight 8K pages but they were too big to be useful so each segment
was always contiguous and could be from 8K to 64K in 8K increments.

At Yale we had an 11/45 with an aftermarket cache that made it nearly
as fast as an 11/70. We also built some of the first bitmapped
terminals, using giant state of the art 2K RAMs. There were 16
terminals each with 32K bytes of memory that could be mapped into both
the 11/45's address space and an adjacent 11/05 that ran a terminal
emulator. The first thing I did was to let you map your terminal
memory into the top half of the data space which was fast but losing
half of your address space was painful.

Then I noticed that the 11/45 had a third supervisor mode intended
between user and kernel with its own address space. Unix didn't use
it, so I mapped the screen memory into supervisor space, set the
program status so that for user programs the supervisor was the
"previous" mode, and then could use hardware move to/from previous
space instructions. The C compiler didn't generate those so we had
some little assembler routines to manage screen memory. It worked
great, the undergrads wasted tons of time writing screen hackery.

[Thomas Koenig]

Post by John Levine
Architectures of any kind die for two reasons: they run out of address
bits, the vandor can't make them competitively fast, or both.

Market share also plays a large role. Large number of systems sold
can support large development teams, which have the resources to
make them better.

And for this, a large software base plays a huge role, hence x86
and the "synergies" between Microsoft and Intel.

[Charlie Gibbs]

Post by Thomas Koenig

Post by John Levine
Architectures of any kind die for two reasons: they run out of address
bits, the vandor can't make them competitively fast, or both.

Market share also plays a large role. Large number of systems sold
can support large development teams, which have the resources to
make them better.
And for this, a large software base plays a huge role, hence x86
and the "synergies" between Microsoft and Intel.

As I always used to say,

The only reason everybody uses COBOL is that everybody uses COBOL.

[Lars Poulsen]

Post by Scott Lurndal
That flat model, of course, predates linux by decades. Linus chose it
because it made sense. Segmented schemes have all been found
lacking.

Segmented schemes make sense in a context. In the early days of single
job at a time, the context would be a language that could express
segments as an embodiment of the semantics of that language. Later, in a
multi-job environment, language semantics was just one aspect of memory
management requirements, task/job separation was another.
A "page" is a segment ... typically of a standardized size.

At the time of this transition, languages were mostly locked in, and
most of them did not have semantics that could generalize to segments,
while paging of virtual memories that were larger than physical memories
simplified things a lot. So the physical memory was managed in segments
called pages, while the virtual memory became flat address space. And
soon it became hard to think of anything different.

Once the "reference model" was C and Unix, it seems nothing else could
get traction.

[Bob Eager]

Post by Lars Poulsen

Post by Scott Lurndal
That flat model, of course, predates linux by decades. Linus chose it
because it made sense. Segmented schemes have all been found lacking.

Segmented schemes make sense in a context. In the early days of single
job at a time, the context would be a language that could express
segments as an embodiment of the semantics of that language. Later, in a
multi-job environment, language semantics was just one aspect of memory
management requirements, task/job separation was another.
A "page" is a segment ... typically of a standardized size.

Pages and segments are not necessarily the same thing.

Some systems have/had both. Large segments (e.g. 256kB), each with
different properties (e.g. read ony, read/write, executable). The smaller
pages to split up each segment for use when implementing virtual memory;
pages all had the properties of the segment.

[Peter Flass]

Post by Lars Poulsen

Post by Vir Campestris
The '286 was mostly just a faster 8086. Its protected mode was brain
damaged.

I used 80286 protected mode in an embedded project, and it was pretty
wonderful. Our code was written in C, and we used a compiler that mated
well with a "DOS Extender" to get beyond the 1MB limitations of the
basic 8086 model. We hacked the "malloc()" to give us a new segment for
each data structure, which gave us hardware bounds checking, which in
turn gave us greatly accellerated debugging.
I always felt that the Linux model of just a flat 32-bit address space
was a big step backwards.

It’s the least common denominator, which is why Linux/Unix is easily
portable to so many diverse systems. The Multics model is much better, but
requires specialized hardware.

Post by Lars Poulsen
286 protected mode was not a full memory management system for a paging
multiuser OS, but there was a use case where it worked VERY well.

[Borax Man]

On Mon, 27 Nov 2023 12:37:22 -0700

Post by Peter Flass

Post by Borax Man
On Sat, 25 Nov 2023 10:30:16 -0700

Post by Peter Flass

Post by David LaRue

Post by Pete

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

https://www.google.com/search?q=80186+assembly+language+tutorial
Peter

For any computer look at the physical layout (registers, addressing, etc.)
and available commands. Now figure out how you or others would acomplish
various goals needed in the tasks you want to accomplish. Sources like
above can offer rules to follow, but perhaps the best way to learn is to do
it yourself and find ways to accomplish your goals. There may be many ways
to accomplish the same goal. Learn to adapt to various goals. Sample
goals could be instruction count, bytes needed for the assembly language,
and assembling your own building blocks for various projects.

For any new language I usually like to start with a working sample program
and then play around and make changes to it to see what’s happening.
--
Pete

Nothing beats having a good book. Unfortunately those targetting the
16 bit intel chips are old and hard to find. Jeff Duntemann's
Assembly Language Step-by-step is good, but current versions are
targetted towards Linux.

Is there anything else?

Hmm, I borrowed some books back in the 90s, but not sure if they are
still around. Maybe look on archive.org for assembly books, you might
find some older ones from te 80s and 90s there.

Get started with the one I linked, and then when you hit a brick wall,
go from there.

Looking at old MS-DOS software sites and old MS-DOS programming sites
may help too. Wikibooks has information, but its spread out.

[Kerr-Mudd, John]

On Wed, 29 Nov 2023 20:48:18 +1100

Post by Borax Man
On Mon, 27 Nov 2023 12:37:22 -0700

Post by Peter Flass

Post by Borax Man
On Sat, 25 Nov 2023 10:30:16 -0700

Post by Peter Flass

Post by David LaRue

Post by Pete

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

https://www.google.com/search?q=80186+assembly+language+tutorial
Peter

For any computer look at the physical layout (registers, addressing, etc.)
and available commands. Now figure out how you or others would acomplish
various goals needed in the tasks you want to accomplish. Sources like
above can offer rules to follow, but perhaps the best way to learn is to do
it yourself and find ways to accomplish your goals. There may be many ways
to accomplish the same goal. Learn to adapt to various goals. Sample
goals could be instruction count, bytes needed for the assembly language,
and assembling your own building blocks for various projects.

For any new language I usually like to start with a working sample program
and then play around and make changes to it to see what’s happening.
--
Pete

Nothing beats having a good book. Unfortunately those targetting the
16 bit intel chips are old and hard to find. Jeff Duntemann's
Assembly Language Step-by-step is good, but current versions are
targetted towards Linux.

Is there anything else?

Hmm, I borrowed some books back in the 90s, but not sure if they are
still around. Maybe look on archive.org for assembly books, you might
find some older ones from te 80s and 90s there.
Get started with the one I linked, and then when you hit a brick wall,
go from there.
Looking at old MS-DOS software sites and old MS-DOS programming sites
may help too. Wikibooks has information, but its spread out.

Get subscribed to alt.lang.asm, comp.lang.asm.x86 and
comp.os.msdos.progammer

(though the only asm you'll see might be my small programs/games)
PS I suggest you ignore Skybuck, he's never on-topic

[Borax Man]

On Mon, 27 Nov 2023 12:37:22 -0700

Post by Peter Flass

Post by Borax Man
On Sat, 25 Nov 2023 10:30:16 -0700

Post by Peter Flass

Post by David LaRue

Post by Pete

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

https://www.google.com/search?q=80186+assembly+language+tutorial
Peter

For any computer look at the physical layout (registers, addressing, etc.)
and available commands. Now figure out how you or others would acomplish
various goals needed in the tasks you want to accomplish. Sources like
above can offer rules to follow, but perhaps the best way to learn is to do
it yourself and find ways to accomplish your goals. There may be many ways
to accomplish the same goal. Learn to adapt to various goals. Sample
goals could be instruction count, bytes needed for the assembly language,
and assembling your own building blocks for various projects.

For any new language I usually like to start with a working sample program
and then play around and make changes to it to see what’s happening.
--
Pete

Nothing beats having a good book. Unfortunately those targetting the
16 bit intel chips are old and hard to find. Jeff Duntemann's
Assembly Language Step-by-step is good, but current versions are
targetted towards Linux.

Is there anything else?

Hmm, I borrowed some books back in the 90s, but not sure if they are
still around. Maybe look on archive.org for assembly books, you might
find some older ones from te 80s and 90s there.

Get started with the one I linked, and then when you hit a brick wall,
go from there.

Looking at old MS-DOS software sites and old MS-DOS programming sites
may help too. Wikibooks has information, but its spread out.

[John Levine]

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186 microprocessor. what would be the best source
for that.

The 80186 was very similar to the 8086 and 8088, and a subset of the
80286, all often as a group called x86.

There's lots of online x86 programming tutorials.

[John Dallman]

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

Learn 8086/8088 first. 80186 only adds a few instructions to that. What
kind of 80186 machine are you interested in?

John

[Syber Shock]

On Sat, 25 Nov 2023 03:32:58 -0800 (PST)

Post by Vansh Kapoor
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.

80186 Manuals: http://rcollins.org/intel.doc/186Manuals.html

FPC has a 8086/80186 cross-compiler. Being old and arcane
documentation might be sparse. If it does still have the target you can
output raw asm for the target and examine it.

Free Pascal compiled programs running on a real 80186 computer: This is
one of the first 16-bit programs, compiled by Free Pascal, running on a
real 80186 computer - the HP 200LX.

The user can flag the FreePascal compiler to output assembly and then
examine the assembly code.

https://wiki.freepascal.org/DOS says that FreePascal supports 80186 as a
16-bit compiler target. It also says this mode allows writing
bootloader and bios code.

If you can find a compiler that targets your preferred chip you can
compile simple programs to assembly. Then you can examine the
generated assembly to see how the functions are translated into
assembler for that target. This is IMHO the best way to learn fast and
see some optimization logic for certain tasks.