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

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

Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:

> 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

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.

David LaRue <huey.dll@tampabay.rr.com> wrote:
> Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
>
>> 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
>
> For any computer look at the physical layout (registers, addressing, etc.)
> and available commands. Now figure out how you or others would acomplish
> various goals needed in the tasks you want to accomplish. Sources like
> above can offer rules to follow, but perhaps the best way to learn is to do
> it yourself and find ways to accomplish your goals. There may be many ways
> to accomplish the same goal. Learn to adapt to various goals. Sample
> goals could be instruction count, bytes needed for the assembly language,
> and assembling your own building blocks for various projects.
>

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

--
Pete

According to Vansh Kapoor <kapoorvansh200@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, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Sat, 25 Nov 2023 10:30:16 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> David LaRue <huey.dll@tampabay.rr.com> wrote:
> > Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
> >
> >> 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
> >
> > For any computer look at the physical layout (registers, addressing, etc.)
> > and available commands. Now figure out how you or others would acomplish
> > various goals needed in the tasks you want to accomplish. Sources like
> > above can offer rules to follow, but perhaps the best way to learn is to do
> > it yourself and find ways to accomplish your goals. There may be many ways
> > to accomplish the same goal. Learn to adapt to various goals. Sample
> > goals could be instruction count, bytes needed for the assembly language,
> > and assembling your own building blocks for various projects.
> >
>
> For any new language I usually like to start with a working sample program
> and then play around and make changes to it to see what’s happening.
>
> --
> Pete

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

You can find a 1992 version here.

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

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

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

--

Borax Man <rotflol2@hotmail.com> wrote:
> On Sat, 25 Nov 2023 10:30:16 -0700
> Peter Flass <peter_flass@yahoo.com> wrote:
>
>> David LaRue <huey.dll@tampabay.rr.com> wrote:
>>> Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
>>>
>>>> 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
>>>
>>> For any computer look at the physical layout (registers, addressing, etc.)
>>> and available commands. Now figure out how you or others would acomplish
>>> various goals needed in the tasks you want to accomplish. Sources like
>>> above can offer rules to follow, but perhaps the best way to learn is to do
>>> it yourself and find ways to accomplish your goals. There may be many ways
>>> to accomplish the same goal. Learn to adapt to various goals. Sample
>>> goals could be instruction count, bytes needed for the assembly language,
>>> and assembling your own building blocks for various projects.
>>>
>>
>> For any new language I usually like to start with a working sample program
>> and then play around and make changes to it to see what’s happening.
>>
>> --
>> Pete
>
>
> Nothing beats having a good book. Unfortunately those targetting the
> 16 bit intel chips are old and hard to find. Jeff Duntemann's
> Assembly Language Step-by-step is good, but current versions are
> targetted towards Linux.

Is there anything else?

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

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

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

Bob Eager <news0009@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.

On Sat, 25 Nov 2023 03:32:58 -0800 (PST)
Vansh Kapoor <kapoorvansh200@gmail.com> wrote:

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

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

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

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

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

Andy Walker <anw@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.

On 2023-11-28, Bob Eager <news0009@eager.cx> wrote:

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

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:
\ / <cgibbs@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.

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.

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

On 2023-11-28, Andy Walker <anw@cuboid.co.uk> wrote:

> On 28/11/2023 16:15, Scott Lurndal wrote:
>
>> Understanding the machine language is often helpful when debugging
>> compiled code from higher-level languages.
>
> Yes, but how many programmers get to worry about such things? If
> a compiler produces an executable that "doesn't work", it's dealt with by
> the compiler writers rather than by the "higher-level" program writers.

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

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@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.

On Mon, 27 Nov 2023 12:37:22 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> Borax Man <rotflol2@hotmail.com> wrote:
> > On Sat, 25 Nov 2023 10:30:16 -0700
> > Peter Flass <peter_flass@yahoo.com> wrote:
> >
> >> David LaRue <huey.dll@tampabay.rr.com> wrote:
> >>> Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
> >>>
> >>>> 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
> >>>
> >>> For any computer look at the physical layout (registers, addressing, etc.)
> >>> and available commands. Now figure out how you or others would acomplish
> >>> various goals needed in the tasks you want to accomplish. Sources like
> >>> above can offer rules to follow, but perhaps the best way to learn is to do
> >>> it yourself and find ways to accomplish your goals. There may be many ways
> >>> to accomplish the same goal. Learn to adapt to various goals. Sample
> >>> goals could be instruction count, bytes needed for the assembly language,
> >>> and assembling your own building blocks for various projects.
> >>>
> >>
> >> For any new language I usually like to start with a working sample program
> >> and then play around and make changes to it to see what’s happening.
> >>
> >> --
> >> Pete
> >
> >
> > Nothing beats having a good book. Unfortunately those targetting the
> > 16 bit intel chips are old and hard to find. Jeff Duntemann's
> > Assembly Language Step-by-step is good, but current versions are
> > targetted towards Linux.
>
> Is there anything else?
>

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

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

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

On Mon, 27 Nov 2023 12:37:22 -0700
Peter Flass <peter_flass@yahoo.com> wrote:

> Borax Man <rotflol2@hotmail.com> wrote:
> > On Sat, 25 Nov 2023 10:30:16 -0700
> > Peter Flass <peter_flass@yahoo.com> wrote:
> >
> >> David LaRue <huey.dll@tampabay.rr.com> wrote:
> >>> Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
> >>>
> >>>> 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
> >>>
> >>> For any computer look at the physical layout (registers, addressing, etc.)
> >>> and available commands. Now figure out how you or others would acomplish
> >>> various goals needed in the tasks you want to accomplish. Sources like
> >>> above can offer rules to follow, but perhaps the best way to learn is to do
> >>> it yourself and find ways to accomplish your goals. There may be many ways
> >>> to accomplish the same goal. Learn to adapt to various goals. Sample
> >>> goals could be instruction count, bytes needed for the assembly language,
> >>> and assembling your own building blocks for various projects.
> >>>
> >>
> >> For any new language I usually like to start with a working sample program
> >> and then play around and make changes to it to see what’s happening.
> >>
> >> --
> >> Pete
> >
> >
> > Nothing beats having a good book. Unfortunately those targetting the
> > 16 bit intel chips are old and hard to find. Jeff Duntemann's
> > Assembly Language Step-by-step is good, but current versions are
> > targetted towards Linux.
>
> Is there anything else?
>

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

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

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

On Wed, 29 Nov 2023 20:48:18 +1100
Borax Man <rotflol2@hotmail.com> wrote:

> On Mon, 27 Nov 2023 12:37:22 -0700
> Peter Flass <peter_flass@yahoo.com> wrote:
>
> > Borax Man <rotflol2@hotmail.com> wrote:
> > > On Sat, 25 Nov 2023 10:30:16 -0700
> > > Peter Flass <peter_flass@yahoo.com> wrote:
> > >
> > >> David LaRue <huey.dll@tampabay.rr.com> wrote:
> > >>> Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
> > >>>
> > >>>> 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
> > >>>
> > >>> For any computer look at the physical layout (registers, addressing, etc.)
> > >>> and available commands. Now figure out how you or others would acomplish
> > >>> various goals needed in the tasks you want to accomplish. Sources like
> > >>> above can offer rules to follow, but perhaps the best way to learn is to do
> > >>> it yourself and find ways to accomplish your goals. There may be many ways
> > >>> to accomplish the same goal. Learn to adapt to various goals. Sample
> > >>> goals could be instruction count, bytes needed for the assembly language,
> > >>> and assembling your own building blocks for various projects.
> > >>>
> > >>
> > >> For any new language I usually like to start with a working sample program
> > >> and then play around and make changes to it to see what’s happening.
> > >>
> > >> --
> > >> Pete
> > >
> > >
> > > Nothing beats having a good book. Unfortunately those targetting the
> > > 16 bit intel chips are old and hard to find. Jeff Duntemann's
> > > Assembly Language Step-by-step is good, but current versions are
> > > targetted towards Linux.
> >
> > Is there anything else?
> >
>
> Hmm, I borrowed some books back in the 90s, but not sure if they are
> still around. Maybe look on archive.org for assembly books, you might
> find some older ones from te 80s and 90s there.
>
> Get started with the one I linked, and then when you hit a brick wall,
> go from there.
>
> Looking at old MS-DOS software sites and old MS-DOS programming sites
> may help too. Wikibooks has information, but its spread out.
>
Get subscribed to alt.lang.asm, comp.lang.asm.x86 and
comp.os.msdos.progammer

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

--
Bah, and indeed Humbug.

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

On 29/11/2023 09:44, John Dallman wrote:
> In article <GAy9N.87597$yvY5.24535@fx10.iad>, cgibbs@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

Vir Campestris <vir.campestris@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.

jgd@cix.co.uk (John Dallman) writes:
>In article <GAy9N.87597$yvY5.24535@fx10.iad>, cgibbs@kltpzyxm.invalid
>(Charlie Gibbs) wrote:
>> On 2023-11-28, Andy Walker <anw@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.

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.

Andy Walker <anw@cuboid.co.uk> writes:
>On 29/11/2023 09:44, John Dallman wrote:
>> In article <GAy9N.87597$yvY5.24535@fx10.iad>, cgibbs@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.

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.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org