Getting started with Assembly language

[Vansh Kapoor]

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

[Pete]

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:

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

Peter

[David LaRue]

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.

[Peter Flass]

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

--
Pete

[John Levine]

According to Vansh Kapoor <kapoorv...@gmail.com>:

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

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

There's lots of online x86 programming tutorials.


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

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

You can find a 1992 version here.

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

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

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


--

[John Dallman]

In article <171769cd-9c92-4206...@googlegroups.com>,

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
kind of 80186 machine are you interested in?

John

[Peter Flass]

Is there anything else?

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



--

Pete

[Vir Campestris]

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

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

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

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

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

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

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

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

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

Andy

[Bob Eager]

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.

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]

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
a larger system. We used them in the mainframe I/O subsystem.

[Syber Shock]

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

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

Free Pascal compiled programs running on a real 80186 computer: This is
one of the first 16-bit programs, compiled by Free Pascal, running on a
real 80186 computer - the HP 200LX.
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]

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.

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

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

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

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

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

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

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

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?)

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.

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

>
>> So, original poster - why do you think you need to learn assembler?
>> Especially for an obsolete chip?
>
> To be fair, the OP didn't claim necessity. Anyone with an academic
>bent is entitled simply to be curious about how things are, or were, done.
>Personally, I hate not knowing things that interest me, and esp hate being
>told that I don't /need/ to know them.

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

[Charlie Gibbs]

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

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

--
/~\ 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]

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

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

[Charlie Gibbs]

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

[John Dallman]

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. BTDTGTS.

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

John

[John Dallman]

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. BTDTGTS.

[Borax Man]

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.

[Borax Man]

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

[Kerr-Mudd, John]

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.

[Vir Campestris]

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.

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

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

Andy

[Andy Walker]

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.

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

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

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

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

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music

Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Soler

[John Dallman]

In article <Nmo9N.36302$Ycdc....@fx09.iad>, sc...@slp53.sl.home (Scott

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

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.

[...]

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

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.

[Scott Lurndal]

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

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

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

[Bob Eager]

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.

[Charlie Gibbs]

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.

> I was a hardware man fixing 2nd. gen. mainframes when they went t/u.

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

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

[John Dallman]

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

[Peter Flass]

Lemme guess - “tits up.”

--
Pete

[Peter Flass]

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

>> And if you need to report compiler bugs, being able to point to exactly
>> what's wrong in the generated code means your bugs get fixed /much/
>> faster.
>
> And it may not even be a compiler bug, but a simple programming
> error. Stepping through the generated assembler with a debugger
> can be quite useful.
>

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

--
Pete

[Peter Flass]

Some days I practically live in the debugger.

>
>>
>>> And if you need to report compiler bugs, being able to point to exactly
>>> what's wrong in the generated code means your bugs get fixed /much/
>>> faster.
>> Yes, but since the 1980s the chances are that the "generated code"
>> is C or similar rather than assembler.
>
> I absolutely disagree with this statement. I haven't used a compiler
> that generates C since C++2.1/3.0 in the early 1990's. I'm not aware of
> any modern compiler (from Ada to Python) that generates intermediate
> C code.
>

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

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

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

[Scott Lurndal]

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 :-).

[Scott Lurndal]

Peter Flass <peter...@yahoo.com> writes:

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

[John Levine]

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.”

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

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

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.╡

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

≈:o)

[Bob Eager]

We have two villages near here, both named Goodnestone.

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

[Bob Martin]

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)

(Bosham is where King Canute had a palace).

[Vir Campestris]

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.

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]

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.

[Bob Eager]

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

[Lars Poulsen]

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.

[John Levine]

According to Lars Poulsen <la...@beagle-ears.com>:

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

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
because it made sense. Segmented schemes have all been found
lacking.

[John Levine]

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.

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.