info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Getting started with Assembly language
243 views
Skip to first unread message
Vansh Kapoor
Nov 25, 2023, 6:33:00 AM11/25/23
to
I am trying to learn/understand assembly language for 80186 microprocessor. what would be the best source for that.
Pete
Nov 25, 2023, 6:59:56 AM11/25/23
to
On 25/11/2023 10:32 pm, Vansh Kapoor wrote:
> 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:
> 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
David LaRue
Nov 25, 2023, 9:52:34 AM11/25/23
to
Pete <pje...@yahoo.com> wrote in news:ujsnjp$2poap$1...@dont-email.me:
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.
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
Nov 25, 2023, 12:30:19 PM11/25/23
to
and then play around and make changes to it to see what’s happening.
--
Pete
John Levine
Nov 25, 2023, 2:24:22 PM11/25/23
to
According to Vansh Kapoor <kapoorv...@gmail.com>:
80286, all often as a group called x86.
There's lots of online x86 programming tutorials.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
>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
>for that.
80286, all often as a group called x86.
There's lots of online x86 programming tutorials.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Borax Man
Nov 25, 2023, 5:28:43 PM11/25/23
to
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.
--
John Dallman
Nov 26, 2023, 6:48:04 AM11/26/23
to
In article <171769cd-9c92-4206...@googlegroups.com>,
kind of 80186 machine are you interested in?
John
kapoorv...@gmail.com (Vansh Kapoor) wrote:
> 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
> I am trying to learn/understand assembly language for 80186
> microprocessor. what would be the best source for that.
kind of 80186 machine are you interested in?
John
Peter Flass
Nov 27, 2023, 2:37:25 PM11/27/23
to
>
> 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
Nov 28, 2023, 6:10:54 AM11/28/23
to
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
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
Nov 28, 2023, 7:23:16 AM11/28/23
to
On Tue, 28 Nov 2023 11:10:51 +0000, Vir Campestris wrote:
> 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
> 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.
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.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Scott Lurndal
Nov 28, 2023, 10:06:55 AM11/28/23
to
Bob Eager <news...@eager.cx> writes:
>On Tue, 28 Nov 2023 11:10:51 +0000, Vir Campestris wrote:
>
>> 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
>On Tue, 28 Nov 2023 11:10:51 +0000, Vir Campestris wrote:
>
>> 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.
a larger system. We used them in the mainframe I/O subsystem.
Syber Shock
Nov 28, 2023, 10:21:33 AM11/28/23
to
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.
https://youtu.be/wscin9RUiTU
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.
--
Baggy Jeans Mafia | https://toot.syfershock.com/profile/crypto/profile
Andy Walker
Nov 28, 2023, 11:09:43 AM11/28/23
to
On 28/11/2023 11:10, Vir Campestris wrote:
> 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 [...].
> Looking back through this thread - some advice from an old wrinkly programmer.
[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++.
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.
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?
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.
--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Ravel
Scott Lurndal
Nov 28, 2023, 11:15:44 AM11/28/23
to
Andy Walker <a...@cuboid.co.uk> writes:
>On 28/11/2023 11:10, Vir Campestris wrote:
>> 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?)
>On 28/11/2023 11:10, Vir Campestris wrote:
>> 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.
m/c must be a British abbreviation for something...
>
>> 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.
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.
>
>> 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.
compiled code from higher-level languages.
Charlie Gibbs
Nov 28, 2023, 2:30:24 PM11/28/23
to
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."
--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgi...@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.
Andy Walker
Nov 28, 2023, 4:17:23 PM11/28/23
to
On 28/11/2023 16:15, Scott Lurndal wrote:
[I wrote:]
>> [...] I started with Atlas [apart from a brief go with
>> Edsac] in '66, and still have a shelf-full of snaffled m/c code, [...].
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.
> 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:]
[...]
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.
[I wrote:]
>> [...] 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.
> m/c must be a British abbreviation for something...
with M/cr, which is Manchester; nor with mc, which is a hammer.
[Vir C:]
>>> 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!
>>> 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.
[...]
> 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
> compiled code from higher-level languages.
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
Nov 28, 2023, 10:53:12 PM11/28/23
to
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
Nov 29, 2023, 4:53:56 AM11/29/23
to
In article <GAy9N.87597$yvY5....@fx10.iad>, cgi...@kltpzyxm.invalid
what's wrong in the generated code means your bugs get fixed /much/
faster.
John
(Charlie Gibbs) wrote:
> On 2023-11-28, Andy Walker <a...@cuboid.co.uk> wrote:
> > 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
> On 2023-11-28, Andy Walker <a...@cuboid.co.uk> wrote:
> > 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.
what's wrong in the generated code means your bugs get fixed /much/
faster.
John
John Dallman
Nov 29, 2023, 4:58:07 AM11/29/23
to
In article <GAy9N.87597$yvY5....@fx10.iad>, cgi...@kltpzyxm.invalid
(Charlie Gibbs) wrote:
(Charlie Gibbs) wrote:
> On 2023-11-28, Andy Walker <a...@cuboid.co.uk> wrote:
> > 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.
> > 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.
Borax Man
Nov 29, 2023, 4:59:11 AM11/29/23
to
On Mon, 27 Nov 2023 12:37:22 -0700
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.
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.
Borax Man
Nov 29, 2023, 5:05:55 AM11/29/23
to
On Mon, 27 Nov 2023 12:37:22 -0700
Kerr-Mudd, John
Nov 29, 2023, 5:34:55 AM11/29/23
to
On Wed, 29 Nov 2023 20:48:18 +1100
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
--
Bah, and indeed Humbug.
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
--
Bah, and indeed Humbug.
Vir Campestris
Nov 29, 2023, 6:54:36 AM11/29/23
to
On 28/11/2023 21:17, Andy Walker wrote:
> On 28/11/2023 16:15, Scott Lurndal wrote:
> [I wrote:]
>>> [...] 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.
>
>> 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
> On 28/11/2023 16:15, Scott Lurndal wrote:
> [I wrote:]
>>> [...] 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.
>
>> 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:]
recently though I think.
>>>> 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!
>
> [...]
>> 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.
>
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
Andy Walker
Nov 29, 2023, 8:46:13 AM11/29/23
to
On 29/11/2023 09:44, John Dallman wrote:
> In article <GAy9N.87597$yvY5....@fx10.iad>, cgi...@kltpzyxm.invalid
> (Charlie Gibbs) wrote:
[I wrote:]
> In article <GAy9N.87597$yvY5....@fx10.iad>, cgi...@kltpzyxm.invalid
> (Charlie Gibbs) wrote:
>>> 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
>>> 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.
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.
> 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.
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.
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Soler
John Dallman
Nov 29, 2023, 8:50:24 AM11/29/23
to
In article <Nmo9N.36302$Ycdc....@fx09.iad>, sc...@slp53.sl.home (Scott
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
Lurndal) wrote:
> m/c must be a British abbreviation for something...
Machine. It's still used for that in the folded source code format I work
> m/c must be a British abbreviation for something...
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
Sn!pe
Nov 29, 2023, 8:59:57 AM11/29/23
to
Vir Campestris <vir.cam...@invalid.invalid> wrote:
> On 28/11/2023 21:17, Andy Walker wrote:
> > On 28/11/2023 16:15, Scott Lurndal wrote:
> > [I wrote:]
> >>> [...] 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.
> >
> >> 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.
[...]
> On 28/11/2023 21:17, Andy Walker wrote:
> > On 28/11/2023 16:15, Scott Lurndal wrote:
> > [I wrote:]
> >>> [...] 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.
> >
> >> 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.
--
^Ï^. Sn!pe, PA, FIBS - Professional Crastinator.
My pet rock Gordon just is.
Google Groups articles not seen here unless poster is whitelisted.
Scott Lurndal
Nov 29, 2023, 9:43:11 AM11/29/23
to
error. Stepping through the generated assembler with a debugger
can be quite useful.
Scott Lurndal
Nov 29, 2023, 9:50:52 AM11/29/23
to
Andy Walker <a...@cuboid.co.uk> writes:
>On 29/11/2023 09:44, John Dallman wrote:
>> In article <GAy9N.87597$yvY5....@fx10.iad>, cgi...@kltpzyxm.invalid
>> (Charlie Gibbs) wrote:
>[I wrote:]
>>>> 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
>On 29/11/2023 09:44, John Dallman wrote:
>> In article <GAy9N.87597$yvY5....@fx10.iad>, cgi...@kltpzyxm.invalid
>> (Charlie Gibbs) wrote:
>[I wrote:]
>>>> 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.
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.
>
>> 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 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.
Bob Eager
Nov 29, 2023, 10:26:58 AM11/29/23
to
On Wed, 29 Nov 2023 13:43:59 +0000, Andy Walker wrote:
> [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.
> [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.]
Charlie Gibbs
Nov 29, 2023, 11:30:30 AM11/29/23
to
On 2023-11-29, Sn!pe <snip...@gmail.com> wrote:
> 'm/c' for 'machine' was standard usage in the late '60s - early '70s;
In some circles, perhaps, but I never saw it.
> '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.
slash notation. It appears in several fields.
Can't fly today, the A/C is U/S.
John Dallman
Nov 29, 2023, 12:13:45 PM11/29/23
to
In article <uk7f6v$rr6v$1...@dont-email.me>, a...@cuboid.co.uk (Andy Walker)
wrote:
> > 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.
> 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
wrote:
> > 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.
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.
> 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.
performance on ordinary hardware and commonly-used operating systems, you
need someone who can dig out and report compiler bugs effectively.
John
Peter Flass
Nov 29, 2023, 2:07:22 PM11/29/23
to
--
Pete
Peter Flass
Nov 29, 2023, 2:07:24 PM11/29/23
to
Scott Lurndal <sc...@slp53.sl.home> wrote:
> j...@cix.co.uk (John Dallman) writes:
>> In article <GAy9N.87597$yvY5....@fx10.iad>, cgi...@kltpzyxm.invalid
>> (Charlie Gibbs) wrote:
>>> On 2023-11-28, Andy Walker <a...@cuboid.co.uk> wrote:
>>>> 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.
>>
> j...@cix.co.uk (John Dallman) writes:
>> In article <GAy9N.87597$yvY5....@fx10.iad>, cgi...@kltpzyxm.invalid
>> (Charlie Gibbs) wrote:
>>> On 2023-11-28, Andy Walker <a...@cuboid.co.uk> wrote:
>>>> 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
>> 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.
>
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.
--
Pete
Peter Flass
Nov 29, 2023, 2:07:25 PM11/29/23
to
>
>>
>>> 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.
>
compilers compile to this and use gcc’s back end to generate machine 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.
>
Pete
Ahem A Rivet's Shot
Nov 29, 2023, 3:30:04 PM11/29/23
to
On Wed, 29 Nov 2023 12:07:19 -0700
Peter Flass <peter...@yahoo.com> wrote:
> Sn!pe <snip...@gmail.com> wrote:
> > '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.
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency
Peter Flass <peter...@yahoo.com> wrote:
> Sn!pe <snip...@gmail.com> wrote:
> > '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.”
--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency
Scott Lurndal
Nov 29, 2023, 4:44:19 PM11/29/23
to
Ahem A Rivet's Shot <ste...@eircom.net> writes:
>On Wed, 29 Nov 2023 12:07:19 -0700
>Peter Flass <peter...@yahoo.com> wrote:
>
>> Sn!pe <snip...@gmail.com> wrote:
>
>> > '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),
>On Wed, 29 Nov 2023 12:07:19 -0700
>Peter Flass <peter...@yahoo.com> wrote:
>
>> Sn!pe <snip...@gmail.com> wrote:
>
>> > '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.
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 :-).
Scott Lurndal
Nov 29, 2023, 4:46:57 PM11/29/23
to
Peter Flass <peter...@yahoo.com> writes:
see or need to debug, however.
>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.
>Scott Lurndal <sc...@slp53.sl.home> wrote:
>> 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
>> 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.
see or need to debug, however.
>Some
>compilers compile to this and use gcc’s back end to generate machine code.
form for a couple decades.
John Levine
Nov 29, 2023, 5:00:31 PM11/29/23
to
According to Peter Flass <peter...@yahoo.com>:
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
>>> 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?
>>> 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.”
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Sn!pe
Nov 29, 2023, 5:41:20 PM11/29/23
to
John Levine <jo...@taugh.com> wrote:
> According to Peter Flass <peter...@yahoo.com>:
> >>> 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.╡
> According to Peter Flass <peter...@yahoo.com>:
> >>> 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.
> >>
> >
> >
>
> Temporarily Unavailable, of course. What else would it stand for?
>
≈:o)
>
> Temporarily Unavailable, of course. What else would it stand for?
>
Bob Eager
Nov 29, 2023, 5:54:53 PM11/29/23
to
They have two totally different pronunciations. One is Good-nes-stone. The
other is Gun-stone.
Bob Martin
Nov 30, 2023, 1:09:57 AM11/30/23
to
On 29 Nov 2023 at 22:54:50, Bob Eager <news...@eager.cx> wrote:
> On Wed, 29 Nov 2023 21:44:16 +0000, Scott Lurndal wrote:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>>On Wed, 29 Nov 2023 12:07:19 -0700 Peter Flass <peter...@yahoo.com>
>>>wrote:
>>>
>>>> Sn!pe <snip...@gmail.com> wrote:
>>>
>>>> > '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)
> On Wed, 29 Nov 2023 21:44:16 +0000, Scott Lurndal wrote:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> writes:
>>>On Wed, 29 Nov 2023 12:07:19 -0700 Peter Flass <peter...@yahoo.com>
>>>wrote:
>>>
>>>> Sn!pe <snip...@gmail.com> wrote:
>>>
>>>> > '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.
(Bosham is where King Canute had a palace).
Vir Campestris
Nov 30, 2023, 5:40:02 AM11/30/23
to
On 29/11/2023 19:07, Peter Flass wrote:
> Some days I practically live in the debugger.
I retired last year. I could afford it, and my time isn't infinite.
> Some days I practically live in the debugger.
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
Juan
Dec 1, 2023, 2:35:42 AM12/1/23
to
On 28/11/2023 15:06, Scott Lurndal wrote:
> 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.
> 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
Dec 1, 2023, 4:19:51 AM12/1/23
to
equivalents, which improved multiply speed.
Lars Poulsen
Dec 12, 2023, 2:35:59 PM12/12/23
to
On 11/28/2023 3:10 AM, Vir Campestris wrote:
> 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.
> 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
Dec 12, 2023, 4:32:31 PM12/12/23
to
According to Lars Poulsen <la...@beagle-ears.com>:
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.
>On 11/28/2023 3:10 AM, Vir Campestris wrote:
>> 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
>> 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.
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
Dec 12, 2023, 6:46:58 PM12/12/23
to
Lars Poulsen <la...@beagle-ears.com> writes:
>On 11/28/2023 3:10 AM, Vir Campestris wrote:
>> 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
>On 11/28/2023 3:10 AM, Vir Campestris wrote:
>> 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
because it made sense. Segmented schemes have all been found
lacking.
John Levine
Dec 12, 2023, 10:31:12 PM12/12/23
to
According to Scott Lurndal <sl...@pacbell.net>:
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.
>>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
>>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.
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
Dec 13, 2023, 2:30:05 AM12/13/23
to
On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
John Levine <jo...@taugh.com> wrote:
> 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
John Levine <jo...@taugh.com> wrote:
> 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.
near and far pointers exposed in the source code.
Scott Lurndal
Dec 13, 2023, 10:07:37 AM12/13/23
to
John Levine <jo...@taugh.com> writes:
>According to Scott Lurndal <sl...@pacbell.net>:
>>>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
>According to Scott Lurndal <sl...@pacbell.net>:
>>>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.
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.
>
>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
>If we'd ended up using something like Pascal or PL/I with stronger
>pointer typing, segmented machines would still be plausible.
data structure size and physical memory checkerboarding when
not combined with some form of paging within the segment).
>
>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.
Charlie Gibbs
Dec 13, 2023, 12:25:21 PM12/13/23
to
On 2023-12-13, Scott Lurndal <sc...@slp53.sl.home> wrote:
> John Levine <jo...@taugh.com> writes:
>> 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 <jo...@taugh.com> writes:
>> 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? :-)
Charlie Gibbs
Dec 13, 2023, 12:25:21 PM12/13/23
to
On 2023-12-13, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
> John Levine <jo...@taugh.com> wrote:
>
>> 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 Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
> John Levine <jo...@taugh.com> wrote:
>
>> 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.
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!
Lars Poulsen
Dec 13, 2023, 12:49:20 PM12/13/23
to
On 12/12/2023 3:46 PM, Scott Lurndal wrote:
> 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
> That flat model, of course, predates linux by decades. Linus chose it
> because it made sense. Segmented schemes have all been found
> lacking.
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.
Ahem A Rivet's Shot
Dec 13, 2023, 1:30:04 PM12/13/23
to
On Wed, 13 Dec 2023 17:25:19 GMT
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2023-12-13, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> > 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.
Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2023-12-13, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>
> > 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.
John Levine
Dec 13, 2023, 4:15:36 PM12/13/23
to
According to Scott Lurndal <sl...@pacbell.net>:
>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
>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.
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.
>>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.
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.
Bob Eager
Dec 13, 2023, 5:33:48 PM12/13/23
to
On Wed, 13 Dec 2023 09:49:17 -0800, Lars Poulsen wrote:
> On 12/12/2023 3:46 PM, Scott Lurndal wrote:
>> 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.
> On 12/12/2023 3:46 PM, Scott Lurndal wrote:
>> 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.
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
Dec 13, 2023, 6:05:53 PM12/13/23
to
Lars Poulsen <la...@beagle-ears.com> wrote:
> On 11/28/2023 3:10 AM, Vir Campestris wrote:
>> 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
> On 11/28/2023 3:10 AM, Vir Campestris wrote:
>> 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.
portable to so many diverse systems. The Multics model is much better, but
requires specialized hardware.
>
> 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.
>
>
Pete
Peter Flass
Dec 13, 2023, 6:05:54 PM12/13/23
to
Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
> John Levine <jo...@taugh.com> wrote:
>
>> 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
> John Levine <jo...@taugh.com> wrote:
>
>> 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.
>
models were just nuts.
--
Pete
Scott Lurndal
Dec 14, 2023, 9:58:08 AM12/14/23
to
John Levine <jo...@taugh.com> writes:
>According to Scott Lurndal <sl...@pacbell.net>:
>>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
>According to Scott Lurndal <sl...@pacbell.net>:
>>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.
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.
>
>>>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
to use the 11/70, but heavily used the 11/780 (loved it!). Our
11/44 ran custom software acting as a terminal controller.
>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.
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.
>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.
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
Dec 14, 2023, 12:18:54 PM12/14/23
to
According to Scott Lurndal <sl...@pacbell.net>:
>>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.
>
>>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
>
>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.
>
>>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.
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.
Charlie Gibbs
Dec 14, 2023, 4:52:09 PM12/14/23
to
John Levine
Dec 14, 2023, 8:47:16 PM12/14/23
to
According to Charlie Gibbs <cgi...@kltpzyxm.invalid>:
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.
>> 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.
>>> 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
>>> near and far pointers exposed in the source code.
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.
>> 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.
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.
Bob Martin
Dec 15, 2023, 2:22:37 AM12/15/23
to
On 14 Dec 2023 at 21:52:06, Charlie Gibbs <cgi...@kltpzyxm.invalid> wrote:
> On 2023-12-13, Peter Flass <peter...@yahoo.com> wrote:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>
>>> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
>>> John Levine <jo...@taugh.com> wrote:
>>>
>>>> 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.
> On 2023-12-13, Peter Flass <peter...@yahoo.com> wrote:
>
>> Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>>
>>> On Wed, 13 Dec 2023 03:31:08 -0000 (UTC)
>>> John Levine <jo...@taugh.com> wrote:
>>>
>>>> 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.
Bob Eager
Dec 15, 2023, 4:18:56 AM12/15/23
to
Manchester MU5. Great for compiler writers.
http://www.ancientgeek.org.uk/ICL/The_ICL_2900_Series.pdf
Ahem A Rivet's Shot
Dec 15, 2023, 6:00:04 AM12/15/23
to
On 15 Dec 2023 07:22:33 GMT
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.
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
Dec 15, 2023, 10:06:59 AM12/15/23
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
Charlie Gibbs
Dec 15, 2023, 1:07:38 PM12/15/23
to
On 2023-12-15, John Levine <jo...@taugh.com> wrote:
> According to Charlie Gibbs <cgi...@kltpzyxm.invalid>:
>
>>>> 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.
>
>>> 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.
> According to Charlie Gibbs <cgi...@kltpzyxm.invalid>:
>
>>>> 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.
>
>>> 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.
Someone once said, "Isn't it fortunate that the iAPX432 flopped?
Otherwise some horrible Intel architecture might have taken over
the world."
Vir Campestris
Dec 15, 2023, 4:23:00 PM12/15/23
to
On 15/12/2023 09:18, Bob Eager wrote:
> 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
> My favourite is the ICL 2900 instruction set - loosely based on the
> Manchester MU5. Great for compiler writers.
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
Dec 15, 2023, 5:40:51 PM12/15/23
to
On Fri, 15 Dec 2023 21:22:57 +0000, Vir Campestris wrote:
> On 15/12/2023 09:18, Bob Eager wrote:
>> 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
> On 15/12/2023 09:18, Bob Eager wrote:
>> 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.
DECsystem-10) for a year. Hoping to build a replica soon.
> 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.
compilers.
Thomas Koenig
Dec 17, 2023, 3:21:53 AM12/17/23
to
John Levine <jo...@taugh.com> schrieb:
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.
> 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
> bits, the vandor can't make them competitively fast, or both.
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
Dec 17, 2023, 9:29:03 PM12/17/23
to
On 2023-12-17, Thomas Koenig <tko...@netcologne.de> wrote:
> John Levine <jo...@taugh.com> schrieb:
The only reason everybody uses COBOL is that everybody uses COBOL.
--
/~\ Charlie Gibbs | Life is perverse.
\ / <cgi...@kltpzyxm.invalid> | It can be beautiful -
X I'm really at ac.dekanfrus | but it won't.
/ \ if you read it the right way. | -- Lily Tomlin
> John Levine <jo...@taugh.com> schrieb:
>
>> 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,
>> 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.
The only reason everybody uses COBOL is that everybody uses COBOL.
--
/~\ Charlie Gibbs | Life is perverse.
\ / <cgi...@kltpzyxm.invalid> | It can be beautiful -
X I'm really at ac.dekanfrus | but it won't.
/ \ if you read it the right way. | -- Lily Tomlin
0 new messages