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
I am trying to learn/understand assembly language for 80186 microprocessor. what would be the best source
for that.
David LaRue <huey.dll@tampabay.rr.com> wrote:c.)=20
Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
=20
On 25/11/2023 10:32 pm, Vansh Kapoor wrote: =20=20
I am trying to learn/understand assembly language for 80186=20
microprocessor. what would be the best source for that. =20
Have you tried a Google search like this:
=20
https://www.google.com/search?q=3D80186+assembly+language+tutorial
=20
Peter =20
For any computer look at the physical layout (registers, addressing, et=
sh=20and available commands. Now figure out how you or others would acompli=
=20various goals needed in the tasks you want to accomplish. Sources like=
o do=20above can offer rules to follow, but perhaps the best way to learn is t=
ways=20it yourself and find ways to accomplish your goals. There may be many =
=20to accomplish the same goal. Learn to adapt to various goals. Sample=
e,=20goals could be instruction count, bytes needed for the assembly languag=
ng.and assembling your own building blocks for various projects.=20
=20
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=E2=80=99s happeni=
=20
--=20
Pete
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.
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.
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.
I am trying to learn/understand assembly language for 80186
microprocessor. what would be the best source for that.
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 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?
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.
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.
[...] I started with Atlas [apart from a brief go withHave you considered donating that to one of the museums (such as CHM?)
Edsac] in '66, and still have a shelf-full of snaffled m/c code, [...].
m/c must be a British abbreviation for something...
The folks that must learn every nook and cranny of the machine languageI'm sure compiler writers still need to know the assembler stuff, butEven most compiler writers can get away with "compiling" into C and
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.
are those who write processor simulators.
Understanding the machine language is often helpful when debugging
compiled code from higher-level languages.
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.
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.
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.
Borax Man <rotflol2@hotmail.com> wrote:etc.)=20
On Sat, 25 Nov 2023 10:30:16 -0700
Peter Flass <peter_flass@yahoo.com> wrote:
=20
David LaRue <huey.dll@tampabay.rr.com> wrote: =20
Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
=20
On 25/11/2023 10:32 pm, Vansh Kapoor wrote: =20=20
I am trying to learn/understand assembly language for 80186=20
microprocessor. what would be the best source for that. =20
Have you tried a Google search like this:
=20
https://www.google.com/search?q=3D80186+assembly+language+tutorial >>>>=20
Peter =20
For any computer look at the physical layout (registers, addressing, =
lish=20and available commands. Now figure out how you or others would acomp=
ke=20various goals needed in the tasks you want to accomplish. Sources li=
to do=20above can offer rules to follow, but perhaps the best way to learn is=
y ways=20it yourself and find ways to accomplish your goals. There may be man=
e=20to accomplish the same goal. Learn to adapt to various goals. Sampl=
age,=20goals could be instruction count, bytes needed for the assembly langu=
gramand assembling your own building blocks for various projects.=20
=20
For any new language I usually like to start with a working sample pro=
ening.and then play around and make changes to it to see what=E2=80=99s happ=
=20=20=20
--=20
Pete =20
=20
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. =20
Is there anything else?
=20
Borax Man <rotflol2@hotmail.com> wrote:etc.)=20
On Sat, 25 Nov 2023 10:30:16 -0700
Peter Flass <peter_flass@yahoo.com> wrote:
=20
David LaRue <huey.dll@tampabay.rr.com> wrote: =20
Pete <pjetson@yahoo.com> wrote in news:ujsnjp$2poap$1@dont-email.me:
=20
On 25/11/2023 10:32 pm, Vansh Kapoor wrote: =20=20
I am trying to learn/understand assembly language for 80186=20
microprocessor. what would be the best source for that. =20
Have you tried a Google search like this:
=20
https://www.google.com/search?q=3D80186+assembly+language+tutorial >>>>=20
Peter =20
For any computer look at the physical layout (registers, addressing, =
lish=20and available commands. Now figure out how you or others would acomp=
ke=20various goals needed in the tasks you want to accomplish. Sources li=
to do=20above can offer rules to follow, but perhaps the best way to learn is=
y ways=20it yourself and find ways to accomplish your goals. There may be man=
e=20to accomplish the same goal. Learn to adapt to various goals. Sampl=
age,=20goals could be instruction count, bytes needed for the assembly langu=
gramand assembling your own building blocks for various projects.=20
=20
For any new language I usually like to start with a working sample pro=
ening.and then play around and make changes to it to see what=E2=80=99s happ=
=20=20=20
--=20
Pete =20
=20
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. =20
Is there anything else?
=20
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 28/11/2023 16:15, Scott Lurndal wrote:
[I wrote:]
[...] I started with Atlas [apart from a brief go withHave you considered donating that to one of the museums (such as CHM?)
Edsac] in '66, and still have a shelf-full of snaffled m/c code, [...].
ÿÿÿÿ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:]
The folks that must learn every nook and cranny of the machine languageI'm sure compiler writers still need to know the assembler stuff, butÿÿÿÿEven most compiler writers can get away with "compiling" into C and
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.
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.
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? IfSometimes. On the other hand, if you have a compiler that's
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.
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/Yes, but since the 1980s the chances are that the "generated code"
faster.
m/c must be a British abbreviation for something...
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.
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.
On 29/11/2023 09:44, John Dallman wrote:
In article <GAy9N.87597$yvY5.24535@fx10.iad>, cgibbs@kltpzyxm.invalid[I wrote:]
(Charlie Gibbs) wrote:
Yes, but how many programmers get to worry about such things? IfSometimes. On the other hand, if you have a compiler that's
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.
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 exactlyYes, but since the 1980s the chances are that the "generated code"
what's wrong in the generated code means your bugs get fixed /much/
faster.
is C or similar rather than assembler.
[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.]
'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.
And if you need to report compiler bugs, being able to point toYes, but since the 1980s the chances are that the "generated code"
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.
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.
Sn!pe <snipeco.2@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.â€
On Wed, 29 Nov 2023 12:07:19 -0700
Peter Flass <peter_flass@yahoo.com> wrote:
Sn!pe <snipeco.2@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.
Scott Lurndal <scott@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.
Some
compilers compile to this and use gcc’s back end to generate machine code.
Ahem A Rivet's Shot <steveo@eircom.net> writes:
On Wed, 29 Nov 2023 12:07:19 -0700 Peter Flass <peter_flass@yahoo.com> >>wrote:
Sn!pe <snipeco.2@gmail.com> wrote:
'm/c' for 'machine' was standard usage in the late '60s - earlyLemme guess - “tits up.â€
'70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u.
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 :-).
On Wed, 29 Nov 2023 21:44:16 +0000, Scott Lurndal wrote:
Ahem A Rivet's Shot <steveo@eircom.net> writes:
On Wed, 29 Nov 2023 12:07:19 -0700 Peter Flass <peter_flass@yahoo.com> >>>wrote:
Sn!pe <snipeco.2@gmail.com> wrote:
'm/c' for 'machine' was standard usage in the late '60s - earlyLemme guess - “tits up.â€
'70s;
I was a hardware man fixing 2nd. gen. mainframes when they went t/u. >>>> >
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.
Some days I practically live in the debugger.
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.
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.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 6 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 28:40:17 |
| Calls: | 45 |
| Files: | 21,492 |
| Messages: | 63,177 |