MASM, TASM or NASM?
Mathias Anler
speed and syntax between NASM, MASM and TASM?
Mark Locke
Mathias,
Your choice of an assembler should be based on your needs/wants. Also,
don't forget the debugger. I have turned down a couple of assemblers because
I was unhappy with the debugger. I chose the A386/D386 which is a souped up
version of A86. My reasons,
1) I liked the debugger (most important)
2) No 'behind your back' assembely, the A86 does not require directives
like PROC,ASSUME,etc,etc. You may use them if you want to though.
3) I progam in Dos, and COM files are easy to produce
4) A386 includes instuctions up to the Athalon Processors (MMX,EMMX,etc)
5) Cost. A86/D86 can be downloaded free. A386/D386 cost 90US$ and comes
with a printed manual. You can save 10$ by getting the manual via disk.
but I don't recommend it,unless you want to sit around and print out 184
pgs.
Shop around and choose the assembler\debugger thats best for you.
Cheers,
Mark
Mathias Anler <mathia...@swipnet.se> wrote in message
news:3868...@news.iglou.com...
Al Leitch [Team2000]
NASM is good if you are already have decent ASM skills and you just want to give
it a try. Also, I'm glad that I decided to use NASM cause not very many people
on the web use it, especially for Win32 programming. Team2000 would be just
another Win32 ASM site if I were to use MASM/TASM, which isn't bad, but I love
the feeling of being unique.
But for your case, start with A86/MASM/TASM. A386 from the way the guy
described sounded cool :)
-----------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
holy cow
>
> I'm new to asm so which assembler should I use? Is there a difference in
> speed and syntax between NASM, MASM and TASM?
Windows, go with MASM. Not that it's necessarily the best (although it
may be), but you'll simply have an easier time with code samples, books,
and integration with the rest of tools (like C compilers, for example.)
Manuel Algora
>I'm new to asm so which assembler should I use? Is there a difference in
>speed and syntax between NASM, MASM and TASM?
For peace of mind: NASM
For wealth of features/tutorials/code: MASM/TASM
To begin with assembler: Wolf's shareware assembler (Wasm). It has a
very nice manual.
Manuel Algora
m...@encomix.es
Manuel Algora
Al Leitch [Team2000]
Actually, I'd say to begin with ASM, use TASM/MASM. Can't beat all the
tutorials and code examples you can get. As a beginner, who wants to read
through a manual to start? I certainly didn't. Yes, WASM came with examples
too, but TASM/MASM has way more and the tutorials are quite invaluable.
----------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
Manuel Algora
On Thu, 30 Dec 1999 03:58:25 GMT, in comp.lang.asm.x86 you wrote:
> As a beginner, who wants to read
>through a manual to start? I certainly didn't.
You just sat in front of a text editor and began writing programs?
Surely you must have read something before. Wolf's assembler manual is
a pleasure to read. I could not bite into x86 assembler for a long
time, until I found it. Then I began to understand how this all works,
and made my first attempts in no time. I wanted to mention this
assembler because hardly anybody recognizes it, and how well suited it
is for the beginner -or in any case, it's manual is. Perhaps HLA is
also a good starting point -I have not had the time to try it yet, but
it looks promising. Of course, personally I would like to be able to
say: start with NASM -the Zen of assembler. If I were not scared at
the prospect, I would try writing some NASM tutorial. Oh, well...
Manuel Algora
m...@encomix.es
Frank Kotler
> Of course, personally I would like to be able to
> say: start with NASM -the Zen of assembler. If I were not scared at
> the prospect, I would try writing some NASM tutorial. Oh, well...
Manuel,
I feel the same way about this Nasm tutorial. I'm not qualified, but
*someone's* got to do it - there's a real need! So I'll show you mine if
you'll show me yours. I've just uploaded a "first draft" to:
http://www.geocities.com/SiliconValley/Heights/1295/clueless.html
This is just a very basic starting point. If it's ever going to amount
to anything, I'm going to need some help and encouragement. So please -
one and all - have a look at this if you've got a moment, and let me
know what it needs.(Lots - I know!)
It occurs to me that the Nasm docs contain most of the info a beginner
needs, but it's interspersed amongst more advanced info. A seperate
"beginner's index" might be some help. I wonder if it would be possible
to obtain permission to use the Nasm docs in this way - possibly have to
add some more "targets", but most of 'em are there...
I'm sure I'm not the only one who's "translated" miscellaneous example
code to Nasm syntax. Mine needs to be cleaned up - better comments, etc.
- before it's ready to post, but I'll try to get to it. With a few
contributions, and some links to existing Nasm examples on the net, the
"all the examples are for Masm/Tasm" objection to Nasm might be
overcome.
The Nasm home-page:
http://www.web-sites.co.uk/nasm/
would be a better place for all this, but it seems less helpful than it
might be. There's a "chat forum" with a place for "examples", but not
too much there. The interface seems difficult - even in the "expert"
section, contributors seem to have trouble posting. (the trick seems to
be: click in the center of the blank page to enter text, then click in
the little narrow border to be able to scroll down to the "submit query"
button) With just a *little* improvement, this could be a great
resource!
I dunno, whaddaya think?
Best,
Frank
Al Leitch [Team2000]
Manuel Algora wrote:
> On Thu, 30 Dec 1999 03:58:25 GMT, in comp.lang.asm.x86 you wrote:
>
> > As a beginner, who wants to read
> >through a manual to start? I certainly didn't.
>
> You just sat in front of a text editor and began writing programs?
Nope, I read some document by a group known as VLA. It discussed the
registers and everything. I would rather have read that than a manual.
Still, alot of it went over my head so I started getting examples off the
web. The examples helped, especially the well commented stuff. One of
the reasons I comment my own stuff. You may want to check out my
bootsector dropper or my boot sector hello world to see my new commenting
style I've borrowed and modified from one of Peter Norton's ASM books.
Sorry I misjudged WASM. The manual sounds like something I'd like to give
a read :) I just wish that I knew about that manual way back when I was
an absolute newbie. Could you provide a link to it?
To all you beginners out there, DO NOT make the same mistake I did and
start with DEBUG! Not the most pleasant and easiest assembler to use.
-------------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
>
> Surely you must have read something before. Wolf's assembler manual is
> a pleasure to read.
> I could not bite into x86 assembler for a long
> time, until I found it. Then I began to understand how this all works,
> and made my first attempts in no time. I wanted to mention this
> assembler because hardly anybody recognizes it, and how well suited it
> is for the beginner -or in any case, it's manual is. Perhaps HLA is
> also a good starting point -I have not had the time to try it yet, but
> it looks promising. Of course, personally I would like to be able to
> say: start with NASM -the Zen of assembler. If I were not scared at
> the prospect, I would try writing some NASM tutorial. Oh, well...
>
> Manuel Algora
> m...@encomix.es
Al Leitch [Team2000]
I shall look this over. About time somebody came up with something like
this. Next goal after DOS NASM tuts is to make NASM Win32 tutorials.
-------------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
Frank Kotler wrote:
> Manuel Algora wrote:
> > Of course, personally I would like to be able to
> > say: start with NASM -the Zen of assembler. If I were not scared at
> > the prospect, I would try writing some NASM tutorial. Oh, well...
>
John Casey
For an absolute beginner the differences between
NASM and TASM/MASM are only a _small_ part of
learning to use assembler.
You need to be able to read and understand MASM
syntax and what the directives do anyway to take
advantage of other sources of information.
Perhaps some clever programmer can write a
program to translate masm/tasm to nasm?
Perhaps a rough draft with warnings and
suggestions if an exact translation is
not possible?
The easiest way might be to get permission
to change a masm tutorial (Art of Assembler)
to include a nasm implementation of the
examples as well?
John.
Al Leitch [Team2000]
NASM:
http://asmjournal.freeservers.com/issues/apj_2.txt
------------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
Manuel Algora
>Manuel,
> I feel the same way about this Nasm tutorial. I'm not qualified, but
>*someone's* got to do it - there's a real need! So I'll show you mine if
>you'll show me yours. I've just uploaded a "first draft" to:
>
>http://www.geocities.com/SiliconValley/Heights/1295/clueless.html
I took a look at it.
When writing such a tutorial, one should decide on start whether one
is trying to teach just NASM, or assembler+NASM. I think a good
approach could be to try to teach NASM, but use links to more detailed
explanations which the beginner could need.
For instance, in you Q&A tutorial, where you have:
-----------------
Q. Wait a minute. How do I know it should be 100h?
A. ".com" files always load at 100h. The preceeding 100h (256 decimal)
bytes are the "Program Segment Prefix" - the PSP -
some information that dos fills in when your program loads. This line
- "org 100h" - is the only clue Nasm needs to generate a
".com" file.
---------------
I would use:
A. The program code actually starts at 100h, because it is always
loaded preceded by 100h bytes which comprise what is known as the PSP
Then I would make that PSP into a link, in case the beginner would
need more info.
The idea is that the text is self-explanatory enough: you don't need
to know anything about the PSP internals to understand why the program
starts at 100h; only that the PSP amounts to a 100h size. But then
there's a link to a more detailed explanation of the PSP. Sort of
OOTutorizing.
>It occurs to me that the Nasm docs contain most of the info a beginner
>needs, but it's interspersed amongst more advanced info.
You have tutorials, which guide you step by step into producing a
program. And you have "Reference Guides", which explain the elements
of the compiler's language, under some classification. NASM
documentation is much of the latter. It's certainly better than TASM
documentation, whose "User's Guide" is really but a reference guide
with such a lack of examples, that it's hardly useful at all.
NASM documentation is a bit messy. It doesn't show all the standards
for a true "Reference Guide," nor does it serve the purpose of a "User
Guide", less so of a tutorial.
The only part of it that looks really consistent is the one devoted to
macro's. The rest of it, has much info interspersed which could have
been classified properly in their own section, so that each and every
element has its own section/subsection. If every element would then
have full examples, with detailed explanation of all the
possibilities, then it could be a very good documentation. But, for
instance, things like the "BITS & USE" issue are put in such a way
that they are hard to grasp by the beginner.
I started to make myself such an attempt to a NASM "Reference Guide".
It may be found at present in
but it is in Spanish, and haven't updated it in a long time. There I
try to provide the elements of the language in such a way that every
element of it is detailed. And that every possibility is taken into
account in a structured manner. Things like:
1) Whether -o is need or not
2) If used:
a) what if the file already exists
a.1) if it's the same name as the source code
a.2) if not
NASM documentation, as it stands now, has you guessing many of those
things. You may find out by trial and error, of course, but...
>I'm sure I'm not the only one who's "translated" miscellaneous example
>code to Nasm syntax. Mine needs to be cleaned up - better comments, etc.
>- before it's ready to post, but I'll try to get to it. With a few
>contributions, and some links to existing Nasm examples on the net, the
>"all the examples are for Masm/Tasm" objection to Nasm might be
>overcome.
That's what we are looking after!
>The Nasm home-page:
>
>http://www.web-sites.co.uk/nasm/
>
>would be a better place for all this, but it seems less helpful than it
>might be.
NASM devotees try to go ahead of what NASM developers are actually
doing. But we can't blame them for that, being a freeware assembler.
Manuel Algora
m...@encomix.es
Manuel Algora
<al__leitch@3*&hotmail.com> wrote:
>Sorry I misjudged WASM. The manual sounds like something I'd like to give
>a read :) I just wish that I knew about that manual way back when I was
>an absolute newbie. Could you provide a link to it?
ftp://ftp.mc.net/pub/users/warp/wasm223.zip
It's not a tutorial on assembler, but a good manual for learning about
the compiler itself, its directives. It's precise, complete, and easy
to understand, so you can begin making programs quickly with it. You
learn to differentiate between assembler code, and directives -the
latter I have always found the greatest stumbling block for the
beginner.
It happens that the most difficult part of learning assembler is not
the assembler language itself. In its core, this just amounts to: you
have bytes (either in RAM, or in registers), and the addresses of
them. The processor instruction set shall give you what operations you
can do on those bytes.
The difficult part of learning assembler comes from understanding the
compiler's "language" itself! Specially with MASM/TASM -may be also
A86 in spite of its claims for non red tape? (not having used it, I'll
show discretion).
You see, NASM, by design, should be easy to use, yet we are
complaining of lack of NASM tutorials. That shows how much the
"compiler's language" is a hard thing to learn -IMO, much harder than
assembler itself.
>To all you beginners out there, DO NOT make the same mistake I did and
>start with DEBUG! Not the most pleasant and easiest assembler to use.
DEBUG is so low level, that it let's you grasp the concept of the real
thing. So I like your idea! Many assembler books and tutorials start
with DEBUG, then they jump to MASM, without making the appropriate
transition, which would allow you to relate immediately the low with
the high. I think every high level feature of an assembler should be
clearly explained in terms of what it amounts to at the DEBUG level.
Books give you a starting template for programs; for instance:
.386
.MODEL SMALL
.STACK
.DATA
; data here
.CODE
.Startup
; code here
.Exit
END
The low level view has been lost! Unless you can clearly relate the
above with the "bytes map" If you lose the "bytes map" view, you are
not programming in pure assembler, but in a high level-like sort of
assembler. And then you are subject to all the quirks of any
high-level approach.
The alternative approach, as provided by HLA, may also be followed,
because HLA is designed from its inception as a HLL which acts as a
tool to learn the concepts of assembler. But MASM/TASM get you in
between: looking as being an assembler, behaving as a HLL. I find that
very messy. With less mess, their HLL features would come very handy,
though.
Manuel Algora
m...@encomix.es
John Casey
Al Leitch [Team2000] wrote:
>
> Here's the best resource I could find for the TASM coder who wishes to try out
> NASM:
> http://asmjournal.freeservers.com/issues/apj_2.txt
>
All I could find was this:
Forbidden
You do not have permission to access this document.
Binary files stored on FreeServers must be accessed
by a local link on a FreeServers user web page.
Thank you for using Free Servers.
Frank Kotler
"Al Leitch [Team2000]" wrote:
>
> Here's the best resource I could find for the TASM coder who wishes to try out
> NASM:
> http://asmjournal.freeservers.com/issues/apj_2.txt
As John has posted, this gets a "forbidden". I had to truncate it to:
http://asmjournal.freeservers.com/issues/
and access apj_2.txt seperately.
Great intro to using Nasm! Thanks, Al.
Best,
Frank
Frank Kotler
John Casey wrote:
>
> For an absolute beginner the differences between
> NASM and TASM/MASM are only a _small_ part of
> learning to use assembler.
Agreed! Seems to me there are three aspects that need to be
learned/taught.
1) The "tools" - this might include a linker and librarian, as well as
the assembler itself.
2) Assembly language - the instruction set and it's operands, how/which
instructions affect the flags - that sort of thing.
3) How to interact with the operating system - the "dos interrupts"
aren't usually called an "API", but it amounts to the same thing.
My prejudice is that an "absolute beginner" ought to start with ".com"
files for dos. Nasm makes this so easy that point 1) can be "soft
pedaled" to start with - advanced features can be learned as needed.
Points 2) and 3) can be introduced a little at a time, with appropriate
pointers to further info.
I don't intend to attempt anything very advanced - I'm barely past the
"absolute beginner" stage myself - but merely to get a program "off the
ground", so we can get on to...
> You need to be able to read and understand MASM
> syntax and what the directives do anyway to take
> advantage of other sources of information.
True, but I manage to learn some from MASM/TASM code and tutorials, even
though I *still* don't know what "assume es=nothing" does for me :)
> Perhaps some clever programmer can write a
> program to translate masm/tasm to nasm?
> Perhaps a rough draft with warnings and
> suggestions if an exact translation is
> not possible?
Great! Please share your code when it's done :) Seriously, I had a brief
go at this, before I realized I was way over my head. Maybe try again
someday... It's come to my attention that PERL is a very powerful
language for this sort of work. Maybe a PERL script would be the way to
go. Any PERL gurus have an opinion?
> The easiest way might be to get permission
> to change a masm tutorial (Art of Assembler)
> to include a nasm implementation of the
> examples as well?
That's a good idea. My feeling was that Randall Hyde's "Art of
Assembler"
http://webster.cs.ucr.edu
relies a bit too heavily on his library code to make a Nasm translation
of the examples easy. Maybe I should look again. I also looked at a
tutorial by "Electric Ed" LeMay
http://www.the-bridge.net/~electrk/
with this idea in mind. Ed has expressed some interest in adding Nasm
support, but is concerned - rightly, I fear - that it might be better to
"stay focused" on Masm/Tasm. You're right that translating the examples
to an existing tutorial would be an easy way to get a Nasm tut going.
Both of these - and many others - are good sources to learn the
non-assembler-specific parts, which as you point out, is a good deal of
what we're trying to learn.
Thanks for the input, John!
Best,
Frank
Al Leitch [Team2000]
Sorry. It worked at the time I posted.
----------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
John Casey wrote:
> Al Leitch [Team2000] wrote:
> >
> > Here's the best resource I could find for the TASM coder who wishes to try out
> > NASM:
> > http://asmjournal.freeservers.com/issues/apj_2.txt
> >
>
John Casey
Now that masm is apparently free I don't see
there being that many beginners wanting to
use nasm. Nasm was written by and I suspect
used by those who already know assembler
and the PC hardware.
All a beginner need to know is how to convert
masm/tasm examples. I used NASMIDE as it flags
syntax errors and referred to the Nasm manual.
At the start I translated my stand alone masm/
tasm source code into a .com program and it
involved mainly doing the following:
Delete stuff like
IDEAL .MODEL small (or MODEL small) STACK 256 (or .STACK)
Replace with
BITS 16
ORG 0x100
..CODE or CODESEG with section .text
..DATA or DATASEG with section .data
..DATA? or UDATASEG with section .bss
delete the word offset
inputbuffer db 256 DUP(?) with inputbuffer resb 256
ambiguous data sizes
mov [number],10 with mov BYTE [number],10
(or mov WORD [number],10
change syntax order
mov [word number],10 with mov WORD [number],10
add brackets to variables
mov ax,result becomes mov ax,[result]
remove PROC and add : to label
remove ENDP and its label
I toyed with the idea of writing a translator
program but do not know how NASM handles libraries
and macros. Examples of such translation would
be of interest to me.
John.
Frank Kotler wrote:
>
> Manuel Algora wrote:
> > Of course, personally I would like to be able to
> > say: start with NASM -the Zen of assembler. If I were not scared at
> > the prospect, I would try writing some NASM tutorial. Oh, well...
>
> Manuel,
> I feel the same way about this Nasm tutorial. I'm not qualified, but
> *someone's* got to do it - there's a real need! So I'll show you mine if
> you'll show me yours. I've just uploaded a "first draft" to:
>
> http://www.geocities.com/SiliconValley/Heights/1295/clueless.html
>
> This is just a very basic starting point. If it's ever going to amount
> to anything, I'm going to need some help and encouragement. So please -
> one and all - have a look at this if you've got a moment, and let me
> know what it needs.(Lots - I know!)
>
> It occurs to me that the Nasm docs contain most of the info a beginner
> needs, but it's interspersed amongst more advanced info. A seperate
> "beginner's index" might be some help. I wonder if it would be possible
> to obtain permission to use the Nasm docs in this way - possibly have to
> add some more "targets", but most of 'em are there...
>
> I'm sure I'm not the only one who's "translated" miscellaneous example
> code to Nasm syntax. Mine needs to be cleaned up - better comments, etc.
> - before it's ready to post, but I'll try to get to it. With a few
> contributions, and some links to existing Nasm examples on the net, the
> "all the examples are for Masm/Tasm" objection to Nasm might be
> overcome.
>
> The Nasm home-page:
>
> http://www.web-sites.co.uk/nasm/
>
> would be a better place for all this, but it seems less helpful than it
Al Leitch [Team2000]
--------------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
Frank Kotler wrote:
> "Al Leitch [Team2000]" wrote:
> >
> > Here's the best resource I could find for the TASM coder who wishes to try out
> > NASM:
> > http://asmjournal.freeservers.com/issues/apj_2.txt
>
Al Leitch [Team2000]
resource in my opinion. Heck, its been known to have uncommon ASM subjects, such as
PIC ASM, X-Windows ASM and more!
BTW, hopefully someone will put out a linker capable of spitting out VxDs and WDM
drivers for us NASM dudes.
David Gravereaux
>I toyed with the idea of writing a translator
>program but do not know how NASM handles libraries
>and macros. Examples of such translation would
>be of interest to me.
The parser/lexer/tree walker routines available in ANTLR 2.7.0
(http://www.antlr.org) might be helpful for such a thing.
I just started coding a translator using it (for something completely different
though).
--
* David Gravereaux *
Tomahawk Software Group
"Things should be as simple as possible, but not simpler." -- Albert E.
John Fine
> True, but I manage to learn some from MASM/TASM code and tutorials, even
> though I *still* don't know what "assume es=nothing" does for me :)
It makes the es register in MASM/TASM work the way it always
works in NASM by turning off two MASM features.
1) Adding ES: overrides for you when it figures out that
you need them. With assume es=nothing, you won't get an
es: override unless you put it in on purpose.
2) Doing segment arithmatic to make things right when
you use es: explicitly for the "wrong" segment. If you
say assume es=XXX and you use es:yyy where yyy is known
to be in segment ZZZ then MASM will tell the linker to
adjust the reference by the difference between ZZZ and
XXX. That is the same linker adjustment you get in
NASM with "WRT XXX" (at least in OBJ format). With the
assume es=nothing you don't enable all that.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/
Frank Kotler
> >http://www.geocities.com/SiliconValley/Heights/1295/clueless.html
>
> I took a look at it.
Thank you!
> When writing such a tutorial, one should decide on start whether one
> is trying to teach just NASM, or assembler+NASM. I think a good
> approach could be to try to teach NASM, but use links to more detailed
> explanations which the beginner could need.
I'm thinking along the lines of Nasm+assembler+dos - just enough of each
to get an "absolute beginner" started. Judging mostly from posts to this
newsgroup, that seems to be the need. Actually, the information is
available - in the docs, and in the \test\ directory - but beginners
seem not to find it. Which proves your point that "links" are the key!
> For instance, in you Q&A tutorial, where you have:
>
> -----------------
> Q. Wait a minute. How do I know it should be 100h?
>
> A. ".com" files always load at 100h. The preceeding 100h (256 decimal)
> bytes are the "Program Segment Prefix" - the PSP -
> some information that dos fills in when your program loads. This line
> - "org 100h" - is the only clue Nasm needs to generate a
> ".com" file.
> ---------------
>
> I would use:
>
> A. The program code actually starts at 100h, because it is always
> loaded preceded by 100h bytes which comprise what is known as the PSP
>
> Then I would make that PSP into a link, in case the beginner would
> need more info.
That's good. I didn't know how much to say, there. Maybe for the
"absolute beginner",
just "A. Shut up and do it!" would be enough :)
> The idea is that the text is self-explanatory enough: you don't need
> to know anything about the PSP internals to understand why the program
> starts at 100h; only that the PSP amounts to a 100h size. But then
> there's a link to a more detailed explanation of the PSP. Sort of
> OOTutorizing.
That's the ticket! Reuseable classes with inheritance! The 3 Meg tut!
Seriously, I hope to use links much as you suggest. I didn't have a link
in mind, and wanted to get something started just to see where it led.
I'm still not sure just what to link to - perhaps a "menu" of links to
varying levels of detail?
> NASM documentation .....
> ..... If every element would then
> have full examples, with detailed explanation of all the
> possibilities, then it could be a very good documentation.
That would be great! If the Nasm docs had links to examples, and perhaps
an "alternative index" with entries like "Com files for dos","Windows
programs using Borland tools", "ELF programs for Linux", "RDF files for
whateveritsfor", etc. it might be the only tutorial anyone would ever
need. Awful pile of work, tho. Would require permission from the
Authors, but I don't imagine such a project would make anyone mad.
> I started to make myself such an attempt to a NASM "Reference Guide".
> It may be found at present in
>
> http://www.ctv.es/USERS/aum/
>
> but it is in Spanish, and haven't updated it in a long time.
Oh, wow, you've already done this! I'm sorry I don't speak Spanish - I
can see that your page is a lot nicer than mine. I'm one of those
monolingual dinosaurs, but Nasm's "net-wide", so resources in other
languages are great.
> There I
> try to provide the elements of the language in such a way that every
> element of it is detailed. And that every possibility is taken into
> account in a structured manner. Things like:
>
> 1) Whether -o is need or not
> 2) If used:
> a) what if the file already exists
> a.1) if it's the same name as the source code
> a.2) if not
That sounds super. Your English seems quite good - consider a
translation?
> >http://www.web-sites.co.uk/nasm/
> NASM devotees try to go ahead of what NASM developers are actually
> doing. But we can't blame them for that, being a freeware assembler.
Far from blame them, I thank them immensely! I think that page is
Jules', and I assume he doesn't have time to "baby-sit" it.
Unfortunately, most of us do have lives which intrude on the really
important things :)
Best,
Frank
Al Leitch [Team2000]
haves:
DOS:
Ralf Brown's Interrupt List:
http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html
HelpPC (Contains all the DOS info and more that you'll need. Even has info
on PSP):
ftp://ftp.simtel.net/pub/simtelnet/msdos/info/helppc21.zip
ftp://garbo.uwasa.fi/pc/programming/helppc21.zip
Assembly Programming Without Interrupts (First page I've seen dedicated to
low level ASM):
http://members.dencity.com/noints/
Win32:
Windows Dissasembler (Good start for newbies):
http://www.expage.com/page/w32dasm
Borland's Win32 API call reference (An ABSOLUTE must have!):
ftp://ftp.borland.com/pub/delphi/techpubs/delphi2/win32.zip
Win32 NASM (Contains must have Win32 related stuff for NASM):
http://rs1.szif.hu/~tomcat/win32/
----------------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
Manuel Algora
>BTW, hopefully someone will put out a linker capable of spitting out VxDs and WDM
>drivers for us NASM dudes.
Why would we need such a linker? I mean, there is already one, coming
with the DDK. NASM is capable of generating COFF files, which MS
linker should be able to make into a device driver. The problem lies
elsewhere, namely: in the library of macros and structures. We would
need to translate them into a NASM syntax.
What I think we need is some sort of "NASM Foundation" to set and
coordinate projects supporting NASM -such as these MASM2NASM
translations and translators.
---------------
Now, Visual Assembler, which is centered around NASM at the present,
promises to be able to produce device drivers. How? May be one of
those more directly involved in the project can answer this.
Manuel Algora
m...@encomix.es
Sven Buschke
Manuel Algora wrote:
>
> On 28 Dec 1999 13:04:26 -0500, in comp.lang.asm.x86 you wrote:
>
> >I'm new to asm so which assembler should I use? Is there a difference in
> >speed and syntax between NASM, MASM and TASM?
>
> For peace of mind: NASM
> For wealth of features/tutorials/code: MASM/TASM
> To begin with assembler: Wolf's shareware assembler (Wasm). It has a
> very nice manual.
>
> Manuel Algora
> m...@encomix.es
>
Where can get Wolf's shareware assembler?
TIA,
Sven.
Manuel Algora
>Where can get Wolf's shareware assembler?
ftp://ftp.mc.net/pub/users/warp/wasm223.zip
Manuel Algora
m...@encomix.es
Johnny Bravo
wrote:
>Manuel,
> I feel the same way about this Nasm tutorial. I'm not qualified, but
>*someone's* got to do it - there's a real need! So I'll show you mine if
>you'll show me yours. I've just uploaded a "first draft" to:
>
>http://www.geocities.com/SiliconValley/Heights/1295/clueless.html
>
>This is just a very basic starting point. If it's ever going to amount
>to anything, I'm going to need some help and encouragement. So please -
>one and all - have a look at this if you've got a moment, and let me
>know what it needs.(Lots - I know!)
Neat, I've just got interested in learning some Assembly over the
last few days (with a background starting with BASIC on TRS-80s way
back when, and recently simple C programs (no graphics or sound, but
everything else up to and including structs and pointers with DJGPP).
This is the first thing useful I've managed to do with NASM, 27 bytes
of executable. The funny thing is the overhead I'm used to with DJGPP
(32-bit protected mode Hello World! produces a 110k executable :).
I like your tutorial, I'd like to advance into things that can
actually be used in my early programs that show important points, here
is a partial list that is roughly in increasing complexity for C
programs. What you could do for these and later programs is give the
info needed to write the program and have the user try to write it
before looking at the actual coded example.
1) A program that inputs your age in years and outputs the number
of seconds in that time. (Show simple input and math)
2) A program that inputs your height in feet and inches (two
entries), then outputs your height in feet as a decimal. (Shows math
on two variables of different types (I have no idea what this means to
assembler but types in C are a big deal :)
3) Input first name, then last name then output as "last, first"
(Introduces Strings and formatted output).
4) A program that uses a loop to calculate the cubes of the numbers 1
to 6. (Shows looping)
5) A program that inputs sex and height, then outputs "Hello,
Sir/Maam you are shorter/taller/equal to the average height for
men/women" (Shows IF branching).
This would be good for starters. Quite a few early level programs
can be constructed from just these basics. From here you can continue
to the more advanced topics like file I/O.
Best Wishes,
Johnny Bravo
Frank Kotler
>
> On 31 Dec 1999 14:05:37 GMT, Frank Kotler <fbko...@nettaxi.com>
> wrote:
> > I've just uploaded a "first draft" to:
> >http://www.geocities.com/SiliconValley/Heights/1295/clueless.html
> Neat, I've just got interested in learning some Assembly over the
> last few days (with a background starting with BASIC on TRS-80s way
> back when, and recently simple C programs (no graphics or sound, but
> everything else up to and including structs and pointers with DJGPP).
> This is the first thing useful I've managed to do with NASM, 27 bytes
> of executable. The funny thing is the overhead I'm used to with DJGPP
> (32-bit protected mode Hello World! produces a 110k executable :).
Yeah, it was this difference in size that got me interested in asm. (tho
I suspect you can reduce that 110k considerably - check the "-o" switch,
etc.) I guess with memory and storage so cheap these days it isn't a big
deal, but bloated executables *offend* me!
> I like your tutorial, I'd like to advance into things that can
> actually be used in my early programs that show important points, here
> is a partial list that is roughly in increasing complexity for C
> programs. What you could do for these and later programs is give the
> info needed to write the program and have the user try to write it
> before looking at the actual coded example.
That's a good idea, tho it sounds almost like "homework". My thought was
to attempt to do the "lab section" - just a quickie for the impatient
beginner who'd like to get *some* kind of code running, rather than
cryptic error messages.
> 1) A program that inputs your age in years and outputs the number
> of seconds in that time. (Show simple input and math)
Okay, what we're inputting is ascii characters. We need to make sure it
really is a "decimal digit" (and cope if it isn't), convert it to the
corresponding *number* - multiply the previous total - if any - by ten,
and then add in the new digit. Then we can begin to multiply. This is
going to overrun 16 bits, so we'll need to use 32-bit registers ( no
problem, we can do this even in 16-bit code - but it limits us to 386+
processors) or we can use 16-bit registers and multiply the "high word"
separately, stash it somewhere temporarily, multiply the "low word", and
add the high words back together. Whew! But it'll run on an 8088. Then
we need to convert back into ascii characters to display it. These are
all routines that beginners will want to learn, and not really that
tough - tho a simpler example keeping the numbers within 16-bits (64k)
might want to come first. Dealing with leap-years is left as an exercise
for the student :)
> 2) A program that inputs your height in feet and inches (two
> entries), then outputs your height in feet as a decimal. (Shows math
> on two variables of different types (I have no idea what this means to
> assembler but types in C are a big deal :)
Types are a big deal in a different way in asm. Nasm doesn't keep track
of 'em at all, which means that *we* have to! The relevant question is
"how many bytes does our variable take up?" You can do...
num1 db 0 ; or "resb 1", we're allocating only one byte
num2 db 0 ; for each variable, in any case
....
mov [num1],ax ; move a word into it :(
and Nasm will cheerfully do what you told it - trashing num2! We also
need to do our own "pointer arithmetic". In "C", p++ will increment p by
1 if p is declared as "pointer to bytes", by two if it's "pointer to
words", and by four if it's "pointer to dwords" - more complicated
increments if it's "pointer to structures". This is straightforward
enough to do, we just have to keep track of it ourselves.
The "decimal" part is harder. We could use "fixed point", I guess (don't
know much about it) or the floating point registers. No experience
there, either, but it looks easy enough, except for the ascii <=> float
conversion. About time I tackled that, I suppose. It would be much
easier to input inches and output feet-and-inches - the "div"
instruction gives us both quotient and remainder ( we use this in the
"number to ascii" conversion).
> 3) Input first name, then last name then output as "last, first"
> (Introduces Strings and formatted output).
This isn't too tough, either as "two inputs" or "one input and parse the
string". Using the dos interrupt services (like the "C" "gets" function)
gives pitiful support for the editing keys. I'm a bad enough typist so I
want my own input routine. I'm still working on it. I can provide a
"default string", and DOSKEY-style "command history", as well as decent
editing-key support. "Features" have been added rather haphazardly, so
the code's a mess, but it works well enough that I'm beginning to be
pleased with it. I don't imagine it will ever be "done". I think this is
a great beginner project - it isn't too hard to improve on the dos
routines, and you can take it as far as you like.
> 4) A program that uses a loop to calculate the cubes of the numbers 1
> to 6. (Shows looping)
Good one! 6 cubed will still fit in a byte register. All kinds of math
routines ( even a naive "multiply" using adds) can be done to
demonstrate the "loop" instruction. I just did the "factorial" function
(n * n-1 * n-2 * ... * 1). This sucker mounts up so fast I had to write
a 64-bit output routine to get *anywhere* with it. (I cheated and used
32-bit registers - limited it to 386+ - 16-bit registers would be a
handful)
> 5) A program that inputs sex and height, then outputs "Hello,
> Sir/Maam you are shorter/taller/equal to the average height for
> men/women" (Shows IF branching).
Okay, but I think a program that outputs sex would have more commercial
potential :) Seriously, this is good - a demo that showed both signed
and unsigned conditional jumps might be even better. It isn't really the
"cmp" that's "signed or unsigned", but the way the "jcc" interprets the
flags. An example that gave these instructions a good workout might be
very useful.
> This would be good for starters. Quite a few early level programs
> can be constructed from just these basics. From here you can continue
> to the more advanced topics like file I/O.
Actually, using the dos services, file i/o - and directory services -
isn't that hard to do. I've got a simple demo of file i/o - just needs
commenting (dammit). A more robust demo (this one doesn't do any error
checking), perhaps getting into "seek" functions, and
"what-to-do-if-the-file-exists" (overwrite/append/cancel, I suppose),
maybe file deletion, changing attributes... Well, that's probably not
this week's project :)
Thanks for the ideas and encouragement, Johnny!
Best,
Frank
Johnny Bravo
>Yeah, it was this difference in size that got me interested in asm. (tho
>I suspect you can reduce that 110k considerably - check the "-o" switch,
>etc.) I guess with memory and storage so cheap these days it isn't a big
>deal, but bloated executables *offend* me!
Most of the extra code is for the protected mode. Not really needed
to print a string to the screen. I could drop things like command
line arguments and other non-needed code and get it down to around
27K. It's overkill to use DJGPP for Hello World! anyway. Worked
great for the guys who wrote Quake though. :)
>That's a good idea, tho it sounds almost like "homework". My thought was
>to attempt to do the "lab section" - just a quickie for the impatient
>beginner who'd like to get *some* kind of code running, rather than
>cryptic error messages.
You can have both, a short info section with a link to the actual
code. Those who want to try it themselves can do so, those who don't
can just go from code example to code example, and refer back to the
explanation when they get stuck. :)
>add the high words back together. Whew! But it'll run on an 8088. Then
>we need to convert back into ascii characters to display it. These are
>all routines that beginners will want to learn, and not really that
>tough - tho a simpler example keeping the numbers within 16-bits (64k)
>might want to come first. Dealing with leap-years is left as an exercise
>for the student :)
Heh, this is so simple in C. But it does need to be done.
No need to worry about leap years, just assume the same 31557600
seconds per year. Just a quick and dirty method of showing some math
and screen IO.
>Seriously, this is good - a demo that showed both signed
>and unsigned conditional jumps might be even better. It isn't really the
>"cmp" that's "signed or unsigned", but the way the "jcc" interprets the
>flags. An example that gave these instructions a good workout might be
>very useful.
Feel free to use whatever you need to in order to show what must be
taught. I'm just using high level concepts to show what needs to be
done, I have no idea how to do these things in asm. :)
>> This would be good for starters. Quite a few early level programs
>> can be constructed from just these basics. From here you can continue
>> to the more advanced topics like file I/O.
>
>Actually, using the dos services, file i/o - and directory services -
>isn't that hard to do. I've got a simple demo of file i/o - just needs
>commenting (dammit). A more robust demo (this one doesn't do any error
>checking), perhaps getting into "seek" functions, and
>"what-to-do-if-the-file-exists" (overwrite/append/cancel, I suppose),
>maybe file deletion, changing attributes... Well, that's probably not
>this week's project :)
>
>Thanks for the ideas and encouragement, Johnny!
You're welcome, and I forgot a couple. Arrays and Random numbers.
With Screen I/O, conditionals, looping, math ,arrays and random
numbers, you can write the omni-present beginner project.
A blackjack program!
If I get that far, I'll have most of the asm I'll ever get around to
using. :)
Best Wishes,
Johnny Bravo
Marshall Price
Too late now; I'm hooked.
(It must've put a hex on me.)
Al Leitch \[Team2000\] wrote:
: To all you beginners out there, DO NOT make the same mistake I did and
: start with DEBUG! Not the most pleasant and easiest assembler to use.
--
Marshall Price (On a Dvorak keyboard: built for comfort and for speed)
d021...@dc.seflin.org http://www.afn.org/~afn49304
Manuel Algora
Randall Hyde
> I like your tutorial, I'd like to advance into things that can
> actually be used in my early programs that show important points, here
> is a partial list that is roughly in increasing complexity for C
> programs. What you could do for these and later programs is give the
> info needed to write the program and have the user try to write it
> before looking at the actual coded example.
>
> of seconds in that time. (Show simple input and math)
> entries), then outputs your height in feet as a decimal. (Shows math
> on two variables of different types (I have no idea what this means to
> assembler but types in C are a big deal :)
> (Introduces Strings and formatted output).
> to 6. (Shows looping)
> Sir/Maam you are shorter/taller/equal to the average height for
> men/women" (Shows IF branching).
>
> can be constructed from just these basics. From here you can continue
> to the more advanced topics like file I/O.
>
> Johnny Bravo
As I am constantly looking for sample program suggestions to
implement as HLA examples for my students, I want you to
know that I appreciate your examples here.
A couple of comments are in order though (keep in mind that
this is coming from an instructor who has seen students mangle
programming assignments over the past decade).
(1) This is actually a much more complex program than it looks
on the surface. Although I realize that you're asking the sample
program to demonstrate simple arithmetic, to correctly solve
your problem needs much more than simple arithmetic.
E.g., for the program to have any meaning whatsoever at
all (the way it's described), you need two inputs: the user's
birthday and the current date and time (granted, you really
need the time of birth, too, but very few people will know that
so it isn't worth asking for it). Then the program has to deal
with issues like leap years (that add an extra 86,xxx seconds
to the total). I won't be anal retentive enough to suggest that
the program consider leap seconds, but they certainly are
a part of the persons age in seconds...
Now I know you think that I've blown this problem all out of
proportion, and if we compare all of this to what you're
really asking for ("teach me how to multiply") your're absolutely
right. However, as an instructor I need to point out the care
that should be taken in sample programs that beginners are
going to use to learn by.
For example, there are some replies to your post where
the author suggests ignoring leap years. Given the trauma
and expense this world has just gone through solving the
Y2K date problem, it's insane to suggest to beginners
that it's okay to cut corners on date algorithms.
Once again, I want to emphasize that I understand where
you're coming from and what you really want. You don't
really care about a date conversion function, you just want
to see a multiplication. I'm just sharing my experiences
as an instructor to suggest that a different example would
probably be a whole lot better here.
On the very positive side, I have solved your five problems
(using HLA) and posted the code at the end of this
article so you can see the HLA solution. The best part
about your post (and why it took me so long to respond)
is that it forced me to write (at least a part of) the datetime
module I've been planning for some time.
Randy Hyde
/***************
1) A program that inputs your age in years and outputs the number
of seconds in that time. (Show simple input and math)
2) A program that inputs your height in feet and inches (two
entries), then outputs your height in feet as a decimal. (Shows math
on two variables of different types (I have no idea what this means to
assembler but types in C are a big deal :)
3) Input first name, then last name then output as "last, first"
(Introduces Strings and formatted output).
4) A program that uses a loop to calculate the cubes of the numbers 1
to 6. (Shows looping)
5) A program that inputs sex and height, then outputs "Hello,
Sir/Maam you are shorter/taller/equal to the average height for
men/women" (Shows IF branching).
*****/
program FiveParts;
#include( "stdlib.hhf" );
// InputInt-
//
// Gets a good input integer between the specified ranges.
// Prompts the user to reenter the data if an input error occurs
// or the value is out of the specified range.
procedure InputInt( prompt:string; lowRange:int32; hiRange:int32 );
nodisplay;
returns( "eax" );
begin InputInt;
forever
stdout.put( prompt, ": " );
try
stdin.FlushInput(); // Force a new input line.
stdin.geti32();
// stdin.get checks to see if the value is within the
// range of a 32-bit integer. Now check to see if it's
// within the range specified by the caller.
if( eax < lowRange ) then raise( ex.ValueOutOfRange );
endif;
if( eax > hiRange ) then raise( ex.ValueOutOfRange );
endif;
// If we fall through to this point, then the input number
// is okay. So break out of the forever loop and return
// the value currently in EAX.
unprotected
break;
// If there were illegal characters in the number,
// tell the user about it and make them re-enter the data.
exception( ex.ConversionError )
stdout.put
"Illegal characters in value, please re-enter" nl
);
// If the value was outside the range lowRange..hiRange
// then tell them about it and make them reenter the data.
exception( ex.ValueOutOfRange );
stdout.put
"Value is out of range, please enter a value between ",
lowRange,
" and ",
hiRange,
nl
);
endtry;
endfor;
end InputInt;
// This procedure asks the user to input their birthday. Then it will
// tell them how old they are in seconds, +/- one day (since they
// probably don't know what time they were born, it's hard to be
// exceptionally accurate here.
procedure ProblemOne;
const
EpochYear := 1900; // Add this value to two-digit years.
readonly
EarliestDate: date.daterec := date.daterec:[ 1, 1, 1850 ];
var
BirthDay: date.daterec;
theDate: date.daterec;
theTime: time.timerec;
begin ProblemOne;
// Output dates in a reasonable fashion:
date.SetFormat( date.mmddyyyy );
// Get the current date and time so we can compute the
// number of seconds since birth.
date.today( theDate );
time.curTime( theTime );
// Get the user's birthday:
InputInt( "Enter the month you were born", 1, 12 );
mov( al, BirthDay.m );
InputInt( "Enter the day you were born", 1, 31 );
mov( al, BirthDay.d );
forever
InputInt( "Enter the year you were born", 1, 9999 );
// If the user entered only a two-digit date, assume
// the H.O. two digits are "19". Obviously this will
// have to be changed at some point to assume the
// year of birth is in the 2000's.
if( eax < 100 ) then
add( EpochYear, ax );
endif;
mov( ax, BirthDay.y );
mov( (type dword BirthDay), eax );
if( eax >= (type dword EarliestDate) ) then
breakif( eax <= (type dword theDate) );
endif;
stdout.put
"That does not seem like a reasonable year." nl
"Please enter a year between "
);
date.print( EarliestDate );
stdout.put( " and " );
date.print( theDate );
stdout.newln();
endfor;
// Okay, convert the birth date and today's date
// to Julian day numbers.
date.Julian( theDate );
mov( eax, ebx );
date.Julian( BirthDay );
sub( eax, ebx );
// EBX contains the number of days the person has been alive.
// Convert that to seconds:
intmul( 60*60*24, ebx );
// Take the current time entered earlier and convert that
// to seconds:
time.HMStoSecs( theTime );
// Sum the two to determine the number of seconds this person
// has been alive:
add( ebx, eax );
// Okay, display the results:
stdout.put
"You have been alive ",
(type uns32 eax),
" seconds,"
nl
"plus or minus about 86,000 seconds depending on the time "
"of your birth" nl nl
);
end ProblemOne;
// This procedure has the user enter their height in
// feet and inches. It displays their height in decimal inches.
procedure ProblemTwo;
readonly
Twelve: real64 := 12.0;
var
Feet: uns32;
Inches: uns32;
decimal:real64;
begin ProblemTwo;
InputInt
"Enter your height in feet and inches, starting with feet",
0,
12
);
mov( eax, Feet );
InputInt( "Enter the inches", 0, 11 );
mov( eax, Inches );
// Compute the decimal height as
// Ht := flt( feet ) + float(inches)/12.0;
fild( Inches );
fld( Twelve );
fdiv();
fild( Feet );
fadd();
fstp( decimal );
stdout.put( "Your height is ", decimal:5:2, " feet." nl nl );
end ProblemTwo;
// Input the user's name as a single string.
// Scan through the string and pick out the user's first
// and last names and display them.
//
// Assumption: since we're only asking for the first and
// last names from the user, if we get more than two words
// assume that the 2nd through Nth words are part of the
// last name (e.g., Van Halen) as opposed to a middle name.
//
// Assumption #2: Names only contain alphabetic characters
// and everything else is to be ignored (sorry, artist with
// unpronouncable name who was formerly known as "Prince"
// but no longer wants to be called the artist formerly known
// as "Prince").
procedure ProblemThree;
var
FullName: string;
Names: string[ 128 ]; // Max words tokenize will find.
begin ProblemThree;
stdout.put( "Enter your full name (first, last): " );
stdin.FlushInput();
stdin.a_gets();
mov( eax, FullName );
str.tokenize2( eax, Names, -{'a'..'z', 'A'..'Z'} );
stdout.puts( "Name:" );
// Output the last name (may be multiple components):
for( mov( 1, ebx); ebx < eax; inc( ebx )) do
stdout.putc( ' ' );
stdout.put( Names[ ebx*4 ] );
endfor;
// Output the first name:
stdout.put( ", ", Names[0], nl nl );
// Free up dynamic storage this code allocates:
strfree( FullName );
for( mov( 0, ebx ); ebx < eax; inc( ebx )) do
strfree( Names[ ebx*4 ] );
endfor;
end ProblemThree;
// The following code prints the cubes of the numbers
// in the range 1..LastValToCube.
procedure ProblemFour;
const
LastValToCube := 6;
procedure cube( ValueToCube:int32 );
nodisplay;
returns( "eax" );
begin cube;
mov( ValueToCube, eax );
intmul( eax, eax );
intmul( ValueToCube, eax );
end cube;
begin ProblemFour;
for( mov( 1, ebx ); ebx <= LastValToCube; inc( ebx )) do
cube( ebx );
stdout.put( (type uns32 ebx), "**3 = ", (type uns32 eax), nl );
endfor;
stdout.newln();
end ProblemFour;
// This procedure has the user enter their height in
// feet and inches. It will tell them if they are above
// or below the average height hard coded into this procedure.
procedure ProblemFive;
readonly
Twelve: real64 := 12.0;
AveHt: real64 := 5 + 7/12; // 5' 7".
var
Feet: uns32;
Inches: uns32;
begin ProblemFive;
InputInt
"Enter your height in feet and inches, starting with feet",
0,
12
);
mov( eax, Feet );
InputInt( "Enter the inches", 0, 11 );
mov( eax, Inches );
// Compute the decimal height as
// Ht := flt( feet ) + float(inches)/12.0;
fild( Inches );
fld( Twelve );
fdiv();
fild( Feet );
fadd();
// Compare the height with the average ht.
fld( AveHt );
fcompp();
fstsw( ax );
sahf();
// Okay, check the flags to see what is going on.
// Note that C=0 if UserHt < AveHt.
if( @z ) then
stdout.put( "You are the average height" nl );
elseif( @nc ) then
stdout.put( "You are below the average height" nl );
else
stdout.put( "You are above the average height" nl );
endif;
end ProblemFive;
begin FiveParts;
ProblemOne();
ProblemTwo();
ProblemThree();
ProblemFour();
ProblemFive();
end FiveParts;
John Casey
>
> As I am constantly looking for sample program suggestions to
> implement as HLA examples for my students, I want you to
> know that I appreciate your examples here.
Although Mr Bravos program suggestions would
be well suited to demo the power of a high level
language like your HLA they would miss what I
consider the whole point in learning assembler
in the first place.
For me assembler means understanding the hardware
of the computer. It means understanding how data
is stored and processed in registers as binary data.
The 'hello, world!' example using int 21h function
ah=9 doesn't explain assembler it's only an example
of how to write the text. The real assembler code
is in the function.
Knowing assembler simply means you can write a
function in assembler if you need to or have the
intellectual satisfaction of having an understanding
of how it all works at the hardware level.
John Casey.
Johnny Bravo
wrote:
>As I am constantly looking for sample program suggestions to
>implement as HLA examples for my students, I want you to
>know that I appreciate your examples here.
>
>A couple of comments are in order though (keep in mind that
>this is coming from an instructor who has seen students mangle
>programming assignments over the past decade).
In reference to the below, I'm basing the examples on increasing
complexity for C programs. Since I can't even figure out how to
address an array element with NASM yet, I have no idea how easy
or difficult these actually are.
>(1) This is actually a much more complex program than it looks
>on the surface.
I posed a simplified version of the program that used none of what
you added. You input your age in years, and it calculates approximate
age in seconds. Age*(seconds per year), then spit out the result.
>Now I know you think that I've blown this problem all out of
>proportion, and if we compare all of this to what you're
>really asking for ("teach me how to multiply") your're absolutely
>right. However, as an instructor I need to point out the care
>that should be taken in sample programs that beginners are
>going to use to learn by.
You can easily substitute anything you want, like the feet in X
fathoms. Sample programs for beginners are just that. Beginners
don't expect to have to deal with all these things in such a simple
program, nor do they want to.
>For example, there are some replies to your post where
>the author suggests ignoring leap years. Given the trauma
>and expense this world has just gone through solving the
>Y2K date problem, it's insane to suggest to beginners
>that it's okay to cut corners on date algorithms.
Then any such program would be impossible for just about anyone.
Since not many people know the exact second they were born in, the
program could not calculate your age in seconds. That is why
beginners don't worry about such things. :)
>On the very positive side, I have solved your five problems
>(using HLA) and posted the code at the end of this
>article so you can see the HLA solution.
LOL, I'm a pretty good C programmer. These things are simple to do
in C. I'm trying to learn how to do them in NASM. I spent three
hours this afternoon trying to program a loop that would create an
array of 256 elements and set each element of the array equal to it's
index without any success. I'm struggling though some examples from
an earlier poster, The Art of Assembler, and the NASM docs.
Best Wishes,
Johnny Bravo
Al Leitch [Team2000]
Team2000's site.
Especially check out the bootsector related stuff. I used a new
commenting style I borrowed and modified from one of Peter Norton's ASM
books. It's definately a newbie's dream come true.
-----------------------------------------------------------------------
Team2000 PC/Palm Pilot Programming Team:
http://ppilot.homepage.com
Johnny Bravo wrote:
> On 8 Jan 2000 23:35:52 GMT, "Randall Hyde" <rh...@shoe-size.com>
> wrote:
>
> >As I am constantly looking for sample program suggestions to
> >implement as HLA examples for my students, I want you to
> >know that I appreciate your examples here.
> >
> >A couple of comments are in order though (keep in mind that
> >this is coming from an instructor who has seen students mangle
> >programming assignments over the past decade).
>
> In reference to the below, I'm basing the examples on increasing
> complexity for C programs. Since I can't even figure out how to
> address an array element with NASM yet, I have no idea how easy
> or difficult these actually are.
>
> >(1) This is actually a much more complex program than it looks
> >on the surface.
>
> I posed a simplified version of the program that used none of what
> you added. You input your age in years, and it calculates approximate
> age in seconds. Age*(seconds per year), then spit out the result.
>
> >Now I know you think that I've blown this problem all out of
> >proportion, and if we compare all of this to what you're
> >really asking for ("teach me how to multiply") your're absolutely
> >right. However, as an instructor I need to point out the care
> >that should be taken in sample programs that beginners are
> >going to use to learn by.
>
> You can easily substitute anything you want, like the feet in X
> fathoms. Sample programs for beginners are just that. Beginners
> don't expect to have to deal with all these things in such a simple
> program, nor do they want to.
>
> >For example, there are some replies to your post where
> >the author suggests ignoring leap years. Given the trauma
> >and expense this world has just gone through solving the
> >Y2K date problem, it's insane to suggest to beginners
> >that it's okay to cut corners on date algorithms.
>
> Then any such program would be impossible for just about anyone.
> Since not many people know the exact second they were born in, the
> program could not calculate your age in seconds. That is why
> beginners don't worry about such things. :)
>
> >On the very positive side, I have solved your five problems
> >(using HLA) and posted the code at the end of this
> >article so you can see the HLA solution.
>
Randall Hyde
John Casey <jgc...@vic.ozland.net.au> wrote in message
news:8592n5$oc8$1...@bob.news.rcn.net...
> Randall Hyde wrote:
> >
> > As I am constantly looking for sample program suggestions to
> > implement as HLA examples for my students, I want you to
> > know that I appreciate your examples here.
>
>
>
> be well suited to demo the power of a high level
> language like your HLA they would miss what I
> consider the whole point in learning assembler
> in the first place.
I think Mr Bravos program suggestions are good ones
insofar as he states "I know C, I want to learn more
about assembly. Give me something I can use to
leverage my existing knowledge when learning
assembly.
>
> For me assembler means understanding the hardware
> of the computer. It means understanding how data
> is stored and processed in registers as binary data.
>
Certainly it is difficult to separate "Machine Organization"
and "Assembly Language Programming." Indeed, the
main reason assembly language is still taught at Colleges
and Universities throughout the world today is mainly
for the "Machine Organization" component. But never
forget that there is the "programming" component too.
Certainly for me, the best way to begin learning a language
is to see how to solve a problem in the language whose
solution I am quite comfortable with in other languages.
> The 'hello, world!' example using int 21h function
> ah=9 doesn't explain assembler it's only an example
> of how to write the text. The real assembler code
> is in the function.
>
> Knowing assembler simply means you can write a
> function in assembler if you need to or have the
> intellectual satisfaction of having an understanding
> of how it all works at the hardware level.
>
> John Casey.
But at what level of abstration do you feel it is necessary
to work at in order to learn what you feel is "assembly"?
Is it not assembly language if I use a UCR Standard Library
Routine like:
print
byte "hello world!",cr,lf,0
Or do I have to drop down to using INTs:
lea dx, HelloWorldStr
mov ah, 9
int 21h
Or do I have to store the characters directly into video memory?
Or do I have to program the CRTCC myself, initializing it, before
I can store characters into video memory?
Etc.
Obviously there are many different levels of abstraction at which
you can work. But the truth of the matter is, print "Hello World!"
on the screen really has nothing whatsoever at all to do with
assembly language programming. Granted, forcing someone to
work at a lower level forces them to learn *more* about assembly
language in order to get their program working at that level
(i.e., storing into video memory requires a greater working
knowledge of assembly than using the PRINT procedure).
However, it takes time to gain this extra knowlede and much
of that knowledge (e.g., video hardware) isn't assembly
language (there are lots of 80x86 machines that don't
have a video display; a knowledge of the 80x86 instruction
set could help you program such machines but any time
you spent learning about the PC's video hardware would
be wasted on such a machine).
While a knowledge of numeric representation, registers,
and basic machine hardware is essential for anyone
wanting to learn assembly language, once you get to
the level of the INT instruction or the PC's peripherals,
you're not really learning assembly language anymore.
You're learning IBM's run-time library (the BIOS) or
you're learning about IBM's hardware designs.
The point I'm trying to make in a long-winded way is that
John Bravo made some reasonable requests for demonstrations
of algorithms that are independent of hardware. My only
disagreement was a warning to those who would implement
such suggestions to be careful about the date example
because it begs for a sloppy solution and it's never a good
idea to propogate incorrect solutions in this business.
Randy Hyde
Randall Hyde
Johnny Bravo <bravo...@usa.net> wrote in message
news:8592n8$ocu$1...@bob.news.rcn.net...
> On 8 Jan 2000 23:35:52 GMT, "Randall Hyde" <rh...@shoe-size.com>
> wrote:
>
>
> >(1) This is actually a much more complex program than it looks
> >on the surface.
>
> I posed a simplified version of the program that used none of what
> you added. You input your age in years, and it calculates approximate
> age in seconds. Age*(seconds per year), then spit out the result.
>
> >Now I know you think that I've blown this problem all out of
> >proportion, and if we compare all of this to what you're
> >really asking for ("teach me how to multiply") your're absolutely
> >right. However, as an instructor I need to point out the care
> >that should be taken in sample programs that beginners are
> >going to use to learn by.
>
> You can easily substitute anything you want, like the feet in X
> fathoms. Sample programs for beginners are just that. Beginners
> don't expect to have to deal with all these things in such a simple
> program, nor do they want to.
I believe my long-winded point was that to teach a simple calculation
involving multiplication you want to use a different example.
Age*seconds_per_year is grossly inaccurate and it's publication
as sample code by those writing tutorials for NASM would
only help bolster the notion that such sloppiness is okay in the
real world. Those of us who are professionals in this business
would like to clean up the poor reputation our profession has;
this starts by avoiding using bad examples beginners might mimic
in their own code. A better solution is to change the variables
around and use something else; Fathoms is a fantastic example.
>
> >For example, there are some replies to your post where
> >the author suggests ignoring leap years. Given the trauma
> >and expense this world has just gone through solving the
> >Y2K date problem, it's insane to suggest to beginners
> >that it's okay to cut corners on date algorithms.
>
> Then any such program would be impossible for just about anyone.
> Since not many people know the exact second they were born in, the
> program could not calculate your age in seconds. That is why
> beginners don't worry about such things. :)
Actually, if you looked at my solution I warned the user that the
answer was in error by about 86,000 seconds since it didn't
get their time of birth. This defect was essentially, "fixed by the
specifications." There is a subtle difference between this
problem (recognizing and articulating the precision of the
program) versus writing code that is simply inaccurate
(especially when the programmer is ignorant of the
cause of the inaccuracies and may employ the same algorithm
in the future when they have to solve the real problem).
>
> >On the very positive side, I have solved your five problems
> >(using HLA) and posted the code at the end of this
> >article so you can see the HLA solution.
>
> LOL, I'm a pretty good C programmer. These things are simple to do
> in C. I'm trying to learn how to do them in NASM. I spent three
> hours this afternoon trying to program a loop that would create an
> array of 256 elements and set each element of the array equal to it's
> index without any success. I'm struggling though some examples from
> an earlier poster, The Art of Assembler, and the NASM docs.
>
> Best Wishes,
> Johnny Bravo
Oh, I fully understand where you are coming from.
I read your post and I know you're trying to learn NASM.
Further, you weren't asking for these sample solutions, only offering
them as suggestions for those who write tutorials on NASM.
I took you suggestions to heart and implemented these five problems
in HLA since I'm working on the pedigogy for HLA as I write this.
I would point out, though, that HLA was invented exactly for people
like you. Those who know a HLL like Pascal or C/C++ and want to
learn how to write programs in assembly language. With HLA, you
could apply your C knowledge and get your array filled in nothing
flat, e.g.,
program fillArray;
static
theArray: uns32[256];
begin fillArray;
for( mov( 0, ebx ); ebx < 256; inc( ebx )) do
mov( ebx, theArray[ ebx*4] );
endfor;
end fillArray;
Of course, there are those who would argue that this is some high level
language, not "true" assembly language. Who am I to argue with such
folk other than to point out that you can do very similar things using the
HLL features of MASM and TASM.
Of course, the above code isn't "pure" assembly language. HLA
compiles this into more primitive machine instructions. But the
beautiful part is that HLA supports those primitive instructions as
well. Therefore, as time passes and you learn more about assembly
language, you'd learn that another way to write the HLA code
above is
program fillArray;
static
theArray: uns32[ 256 ];
begin fillArray;
mov( 0, ebx );
lbl: mov( ebx, theArray[ ebx*4 ] );
inc( ebx );
cmp( ebx, 256 );
jb lbl;
end fillArray;
The nice thing about HLA is that you don't have to learn
everything all at once. You can learn about the HLA HLL
type statements (IF, WHILE, FOR, etc.) and write "C programs
in assembly language" while you're mastering things like
data types, addressing modes, etc. Then, slowly, you
can begin dropping the crutches of the HLL statements
(or, better yet, learn when its appropriate to use the
HLA HLL statements for readability and maintanability and
when to use the "pure assembly" code [spaghetti :)] for
efficiency reasons).
Randy Hyde
P.S. HLA isn't quite ready for beginners yet. So don't
consider this promotional piece as an advertisement
that beginners should jump in and start using HLA.
I expect HLA to get to that point sometime this summer.
This editorial is mainly intended to help clarify the
eventual purpose of HLA.
John Casey
>But at what level of abstration do you feel it is necessary
>to work at in order to learn what you feel is "assembly"?
>Is it not assembly language if I use a UCR Standard Library
>Routine like:
>
> print
> byte "hello world!",cr,lf,0
>
>Or do I have to drop down to using INTs:
>
> lea dx, HelloWorldStr
> mov ah, 9
> int 21h
>
>Or do I have to store the characters directly into video memory?
>Or do I have to program the CRTCC myself, initializing it, before
>I can store characters into video memory?
>
>Etc.
It is assembly at any level. But if all you
learn is how to call routines from a library
you are using the assembler as a HLL and can
only understand it at that level.
I don't know the needs of your students.
Programming is problem solving. Some people
like to analyse and solve problems and know
how things work. Others don't. I think if
your students belong to the first group they
will learn easily otherwise they probably
should take another course.
It helps to have _interesting_ problems
to solve.
The reason I learnt assembler was to speed
up the graphics on my first computers the C64
and Amiga. I have also used it interfacing
to hardware.
John Casey.
Johnny Bravo
On Mon, 10 Jan 2000 00:39:29 GMT, "Randall Hyde" <rh...@shoe-size.com>
wrote:
>I would point out, though, that HLA was invented exactly for people
>like you. Those who know a HLL like Pascal or C/C++ and want to
>learn how to write programs in assembly language. With HLA, you
>could apply your C knowledge and get your array filled in nothing
>flat, e.g.,
After many hours of trial, error and RTFM, I still don't have it.
My entire problem (as I mentioned before), is my lack of understanding
of the MOV command. This is as close as I can get.
org 100h
section .data
section .bss
state resb 256
section .text
mov cx,255
aloop:
mov bx, cx
mov [state+bx],cx
loop aloop
exit:
mov ah,04Ch
int 021h
Best Wishes,
Johnny Bravo
Johnny Bravo
wrote:
>I think Mr Bravos program suggestions are good ones
>insofar as he states "I know C, I want to learn more
>about assembly. Give me something I can use to
>leverage my existing knowledge when learning
>assembly.
We all have our own pile of experience to draw upon.
Thus my disclaimer. After all it took me more than 6
hours to figure out how to do this in NASM.
for (x=0;x<256;x++)
s[x]=x;
Going from BASIC to C, it took about 6 minutes. :)
My problem is that I still have a very poor understanding
of the MOV command. I'm not used to a language where I can't
just assign any number into any variable that can hold it in the
given number of bits.
s[3]=s[2]+s[1]; in asm is way beyond my current understanding.
>Certainly it is difficult to separate "Machine Organization"
>and "Assembly Language Programming." Indeed, the
>main reason assembly language is still taught at Colleges
>and Universities throughout the world today is mainly
>for the "Machine Organization" component.
The early chapters of "The Art of Assembly" are a great source
for this information. Unlike higher level languages, this info
is extremely important. Reading it only once is probably the
source of some of my problems learning the rest.
>But never
>forget that there is the "programming" component too.
>Certainly for me, the best way to begin learning a language
>is to see how to solve a problem in the language whose
>solution I am quite comfortable with in other languages.
That is the sort of newbie page I'm looking for. First
I learn how to do things, then I can figure out how it was done.
Then I extend the knowledge and use it to do something similar.
Best Wishes,
Johnny Bravo
Frank Kotler
Johnny Bravo wrote:
> LOL, I'm a pretty good C programmer. These things are simple to do
> in C. I'm trying to learn how to do them in NASM.
I've just posted my version of "The Five Problems" to my web site:
http://www.geocities.com/SiliconValley/Heights/1295/
I won't post it here as it's a bit longer than Prof. Hyde's solution in
HLA! Assembles to a cow of almost 2.5K! Could be tightened up a lot.
Does most of what you asked about.
Professor Hyde makes a good point about passing sloppy solutions on to
beginners. I hope not to do that, but I make no representations that
this stuff is "Y3K Compliant" - its newbie examples! Surely all of it
should be optimized, improved, made more robust, and thoroughly tested
before you try to re-program your pacemaker with it.
After making this good point, Professor Hyde goes on to guess at the
century and note that it will have to be changed. I *make* ya enter a
four digit year! I then go on to not thoroughly validate the rest of the
date. You can input a birthdate in the future - so long as it's in the
current year - and I don't catch it. It thinks you're awfully old - many
seconds - but incorrect. Fixing it will be a learning experience. I
"bail out" on the exact number of seconds by just calclating whole
number of years and reporting "more than" N seconds.
I cribbed the "nitty-gritty" of the floating-point code from Prof.
Hyde's solution - it was the only part that looked like assembly
language :) First floating point code I ever tried, so it could be badly
broken, and is surely sub-optimal. Seems to work.
My solution to the "lastname, firstname" parsing is a trivial in-line
solution. Professor Hyde's solution is much more versitile. I think I'm
even beginning to understand what "tokenizing" means, tho the details of
how it's done aren't shown in the HLA source.
> I spent three
> hours this afternoon trying to program a loop that would create an
> array of 256 elements and set each element of the array equal to it's
> index without any success.
Byte array?
section .bss
myarray resb 100h
section .text
...
mov si,myarray
xor bx,bx
mov cx,100h
doitagain:
mov byte[si+bx],bl
inc bx
loop doitagain
...
That's "off the cuff" so it may not even assemble. Or maybe not what you
wanted. There's some array-handling code in the "clparam" and "clsort"
examples, I think. Word arrays - pointers to strings. It's fairly
convoluted, and could be improved a lot.
Later,
Frank
John Casey
Johnny Bravo wrote:
> My problem is that I still have a very poor understanding
> of the MOV command. I'm not used to a language where I can't
> just assign any number into any variable that can hold it in the
> given number of bits.
>
> s[3]=s[2]+s[1]; in asm is way beyond my current understanding.
>
It has to be broken into steps.
and you have to take care of the
type of data. eg for words
;point si at start of array
;mov si,s (or mov si,offset s for masm)
s = s[2] ;mov ax,[si + 2 * 2]
s = s + s[1] ;add ax,[si + 1 * 2]
s[3] = s ;mov [si + 3 * 2],ax
In memory it looks something like this:
[si]-> s 00 s[0]
00
00 s[1]
00
00 s[2]
00
00 s[3]
00
This is why I think assembler is easier if
you have a clear picture of the memory as
a list of bytes and a clear picture how
data is stored and processed at that level.
John.
John Casey
> My entire problem (as I mentioned before), is my lack of understanding
> of the MOV command. This is as close as I can get.
>
> org 100h
> section .data
>
> section .bss
> state resb 256
>
> section .text
> mov cx,255
> aloop:
> mov bx, cx
> mov [state+bx],cx
> loop aloop
> exit:
> mov ah,04Ch
> int 021h
>
> Best Wishes,
> Johnny Bravo
>
The MOV command is like the =
mov ax,43 same as ax = 43 where ax is a word.
mov ax,[bx] something like ax = memory[bx]
where memory is a long list bytes and thus
ax = memory[bx]+memory[bx+1]*256
In assembler you have the registers in the
CPU and a really long list of bytes (char)
as memory to store all your data.
In the example you gave you are treating your
reserved memory as an array of BYTES.
You must point bx at the start of your array
and inc after each mov to point to the next
item. If they were words you would inc bx
twice.
org 100h
section .data
section .bss
state resb 256
section .text
mov cx,0 ;cx = 0
mov bx,state ;bx = address of state
aloop:
mov [bx],cx ;memory[bx] = cx
;now bx has the address of the start of the byte array.
inc cx ;cx = cx + 1
cmp cx,256 ;if cx - 256 == 0 set zero flag
jnz aloop ;if zero flag not set jump to aloop
exit:
mov ah,04Ch
int 021h
Why didn't I use the LOOP instruction?
Because I think it is better to learn with
generic instructions found in all CPU types.
Special purpose instructions _should_ be used
but first you need a clear picture of what
is happening to the registers when you use
them.
bx is being used as a pointer to data in
a char array. Except in reality the memory
is one long character array that has to
be used for all kinds of data including
holding the instructions.
John.
Warwick Barnes
Thank you for clarifying something that has been bothering me for
some time. I do rather feel that your HLA is not "real" assembly
language (Thats not particularly a criticism as it may do exactly
what you wish of it), and the latest versions of MASM and TASM whilst
able, like you say for HLA, to convert assembly language of a sort to
binary code, are mostly no longer "real" assembly language.
The problem is two fold firstly operating systems are trying very
hard to make sure that no one goes near the hardware, and secondly
the move by the commercial programming fraternity to turn it into an
arcane cult that only the initiate can adhere to and enter. Thank god
for newsgroups like this one.
If you look at assembler source code of ten years ago most lines of
code dealt with mnemonics for machine instructions, nowadays most
lines seem to be(or contain) assembler instructions (alright I expect
that is an over exaggeration but it makes the point :-) ).
In fact I would recommend anybody wishing to learn "assembly
language" to use A86/D86 and when they have mastered that, to
register it and get A386/D386. With this assembler you at least get
out what you put in. One of the most frustrating things to the
person learning is the errors they make in assembler directives,
which are basically not documented in any clear fashion, how many
times do you see the old hands dismiss a piece of erroring code with
a simple change, everybody knows you have to ... MASM... under .....
Well do we?
Hard copy books are difficult to find but there is usually one around
covering the basics, Generally once past the basics what every
budding assembler needs is a good comprehensive reference book,
something along the lines of K&R plus the compiler library manuals
for C , and these are nowadays sadly lacking . So we all of us I
suspect use the web resources, Ralph brown's interrupt list, Help pc,
Dosref, Randall Hyde's art of assembly language, Intel manuals,
wotsits file formats, etc but these are a nuisance as to check
something out, you have to stop what you are doing and search your
own personal online database. so much easier if a single reference
book (preferably hardback) was available.
Also I notice a tendency for current authors to make assumptions
about peoples knowledge of earlier systems and to leave whole chunks
of information to their bibliography of out of print books many of
which have been discarded by public libraries, so that those who do
not have access to academia, or our own copies of old books are
stuffed. I must have had at least 10 out of print books on search
from Amazon.com 8 of which they have responsed as totally
unavailable. The only one to turn up was in fact a new edition, which
had been modified so much (eg C converted to C++ dos 16 bit to Win 32
etc) that I found it hard to justify as having any connection
whatsoever with what I ordered.
In the old days assembly language was treated as more mechanical, if
you do this the result/effect will be such and such, We were dealing
with machines and we knew how to do that, output tended to be hard
copy. Now high level languages deal with machine intelligences, but
the reality is that these are only layers of software and at the end
of the day we still feed a machine a stream of ones and zeros, and
get out a similar stream which we interpret in a certain way.
I expect then each person should rephrase their question, at which
point the answer will hopefully become more obvious.
If they want to learn assembler and machine operations then an
assembler like A86 is going to do that. If they want to add to their
commercial expertise then TASM/MASM are most likely required. If
they want to join the Free software movement then NASM is probably
the best, and somewhere there are niches for the likes of HLA, debug
and the Ketman interpreter. Of course it may be best to start
somewhere other than where you want to end up and that is surely the
job of the educator to plot a course for the student to steer by.
One other problem, identified by Howetzen Hill years ago was that
most assembler instruction are unneccessary most of the time and you
only need about 40 or so. A usefull guide for newbeys would be to
tell them which 40 and why. I'll leeve it to my peers to make up a
definitive list, of course a small programme which searched through
source code and presented a frequency table for each instruction,
would make a nice example, with a useful end product.
Johnny Bravo
On 10 Jan 2000 17:07:19 -0500, John Casey <jgc...@vic.ozland.net.au>
wrote:
>The MOV command is like the =
>mov ax,43 same as ax = 43 where ax is a word.
>mov ax,[bx] something like ax = memory[bx]
>where memory is a long list bytes and thus
>ax = memory[bx]+memory[bx+1]*256
I've got this much, I just get lots of compiler errors
due to having my application of mov. Like
mov cx,0
mov [state+cx],cx
>In assembler you have the registers in the
>CPU and a really long list of bytes (char)
>as memory to store all your data.
Luckily for me I've got a decent grounding in memory
and storage from learning about pointers in C.
>bx is being used as a pointer to data in
>a char array. Except in reality the memory
>is one long character array that has to
>be used for all kinds of data including
>holding the instructions.
I see what I was doing incorrectly. I was trying to access
state+offset directly in the mov instruction. [state+offset],
rather than [pointer+offset].
Best Wishes,
Johnny Bravo
Johnny Bravo
On Mon, 10 Jan 2000 21:04:45 GMT, Frank Kotler <fbko...@nettaxi.com>
wrote:
>
>Johnny Bravo wrote:
>> LOL, I'm a pretty good C programmer. These things are simple to do
>> in C. I'm trying to learn how to do them in NASM.
>
>I've just posted my version of "The Five Problems" to my web site:
>
>http://www.geocities.com/SiliconValley/Heights/1295/
Thanks! I've already downloaded the other examples and are learning
quite a bit from them.
Best Wishes,
Johnny Bravo
Frank Kotler
> org 100h
> section .data
>
> section .bss
> state resb 256
>
> section .text
> mov cx,0 ;cx = 0
> mov bx,state ;bx = address of state
> aloop:
> mov [bx],cx ;memory[bx] = cx
> ;now bx has the address of the start of the byte array.
> inc cx ;cx = cx + 1
> cmp cx,256 ;if cx - 256 == 0 set zero flag
> jnz aloop ;if zero flag not set jump to aloop
> exit:
> mov ah,04Ch
> int 021h
You're stuffing a word (cx) into a byte array, something Nasm will
cheerfully do for you. Assemblers that keep track of "types" would
probably flag an error on this. This should work anyway, as long as
you're counting up (which you're not - I don't see bx being incremented
anywhere) until you get to the last element (at which point you're
trashing the following byte, if any). In the example I posted to JB, I
originally wrote "mov [si+bx],bx", then thought (incorrectly!) "that's
an ambiguous instruction size" (it's not), so I wrote "mov
byte[si+bx],bx" and that was obviously enough wrong so I caught it (but
it probably has friends). Reading a word out of a byte array will
obviously give wrong results, too - this might lead you to think you're
further from a correct solution than you actually are.
> Why didn't I use the LOOP instruction?
> Because I think it is better to learn with
> generic instructions found in all CPU types.
> Special purpose instructions _should_ be used
> but first you need a clear picture of what
> is happening to the registers when you use
> them.
Good point!
> bx is being used as a pointer to data in
> a char array. Except in reality the memory
> is one long character array that has to
> be used for all kinds of data including
> holding the instructions.
Right. We can address that array as words or dwords or structures of
some arbitrary size, but we've got to keep track of "types" - the
size-in-bits/bytes of our data item - ourselves. Nasm isn't going to do
"pointer arithmetic" for us.
Best,
Frank
John Casey
>
> John Casey wrote:
>
> > org 100h
> > section .data
> >
> > section .bss
> > state resb 256
> >
> > section .text
> > mov cx,0 ;cx = 0
> > mov bx,state ;bx = address of state
> > aloop:
> > mov [bx],cx ;memory[bx] = cx
> > ;now bx has the address of the start of the byte array.
> > inc cx ;cx = cx + 1
> > cmp cx,256 ;if cx - 256 == 0 set zero flag
> > jnz aloop ;if zero flag not set jump to aloop
> > exit:
> > mov ah,04Ch
> > int 021h
>
> You're stuffing a word (cx) into a byte array, something Nasm will
> cheerfully do for you. Assemblers that keep track of "types" would
> probably flag an error on this. This should work anyway, as long as
> you're counting up (which you're not - I don't see bx being incremented
> anywhere) until you get to the last element (at which point you're
> trashing the following byte, if any).
Yikes! I modified Bravos code without thinking
or testing it.
Is this better?
org 100h
section .bss
state resb 256
section .text
mov cx,0
mov bx,state
aloop:
mov [bx],cl ;cl not cx
inc cx
inc bx ;bump the pointer
cmp cx,256
jnz aloop
exit:
mov ah,04Ch
int 021h
John.
Frank Kotler
> I've got this much, I just get lots of compiler errors
> due to having my application of mov. Like
> mov cx,0
> mov [state+cx],cx
I think the problem is not with the "mov", per se, but with the
[state+cx]! Using 16-bit registers, that's only legal with bx, si, and
di. With 32 bit registers, any register can be used in this way. Try
using bx (base register) or si or di (index registers). you can use
base+index, but not index+index. IOW [state+bx+si] should work, but not
[state+di+si]. One of those things "everybody knows" - so nobody
mentions...
Best,
Frank
John S. Fine
> Luckily for me I've got a decent grounding in memory
> and storage from learning about pointers in C.
Be careful of one very important difference. In C,
when you add an index (an integer) to a pointer, the
compiler automatically multiplies the index by the
size of the object pointed to. So if X[] is an
array of short integers X[5] is the integer starting
at byte offset 10 relative to X. If X[] were long
integers then it would be offset 20.
In assembler you don't get that multiply unless you
code it yourself. If X[] is that array of short
integers then:
mov bx,5
mov ax,[X+bx]
This does not get element 5. It gets the (misaligned)
element at offset 5.
mov ebx,5
mov ax,[X+ebx*2]
This gets element 5; But using 32 bit registers in 16
bit mode may be slow and this method doesn't work with
16 bit registers.
mov bx,5
add bx,bx
mov ax,[X+bx] ;This also works
mov bx,10
mov ax,[X+bx] ;And this works
mov ax,[X+10] ;And this works
> I see what I was doing incorrectly. I was trying to access
> state+offset directly in the mov instruction. [state+offset],
> rather than [pointer+offset].
Actually, that wasn't your error. You can have an array name
as the constant part of an address and the index as the register
part of the address. You just are limited in which register you
use. You tried it with CX. You can do it with BX, SI or DI.
If BP is available and you are in a compatible memory model, or
you use as DS: override then you could use BP as well (but a
beginner is better off using just BX, SI and DI for that
purpose).
Here is my simplified version of the sample program you have
been discussing
org 100h
section .bss
state resb 256
section .text
xor bx,bx ;Shorter than "mov bx,0"
aloop:
mov [state+bx],bl
inc bl
jnz aloop
exit:
mov ah,04Ch
int 021h
Because 265 has a low byte of zero, I used "inc bl" instead
of both the "inc bx" and the "cmp bx,256". I know that is a
little advanced for beginners, but if you don't want to start
thinking of things like that, you would be better off coding in
C.
Even that change probably saves just space and not time (depends
on which CPU you are using), so whether you actually do something
like that depends on what you are trying to achieve in a given
section of code.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/
Johnny Bravo
On 11 Jan 2000 04:57:19 GMT, Frank Kotler <fbko...@nettaxi.com>
wrote:
>You're stuffing a word (cx) into a byte array, something Nasm will
>cheerfully do for you.
More pieces of my incomplete understanding are filled in. I didn't
even think that I was trying to stuff a 16 bit register into an 8 bit
byte. I was thinking that I was putting the value at that location
into the byte, but I know Nasm chokes on mov [state+cx],[cx] and I
didn't know of a different way to do it. I'm glad I'm getting plenty
of instructional help here. :)
>obviously give wrong results, too - this might lead you to think you're
>further from a correct solution than you actually are.
Thanks, the more I read here, the clearer it all becomes.
Best Wishes,
Johnny Bravo
Johnny Bravo
On 11 Jan 2000 07:44:39 -0500, Frank Kotler <fbko...@nettaxi.com>
wrote:
>Johnny Bravo wrote:
>> I've got this much, I just get lots of compiler errors
>> due to having my application of mov. Like
>> mov cx,0
>> mov [state+cx],cx
>
>I think the problem is not with the "mov"
Heh, like I mentioned. It was with my application of mov.
I was using it wrong, but had no idea why it was wrong. :)
>[state+cx]! Using 16-bit registers, that's only legal with bx, si, and
>di. With 32 bit registers, any register can be used in this way. Try
>using bx (base register) or si or di (index registers). you can use
>base+index, but not index+index. IOW [state+bx+si] should work, but not
>[state+di+si]. One of those things "everybody knows" - so nobody
>mentions...
Much thanks, every little piece fills in some of the gaps.
Best Wishes,
Johnny Bravo
Johnny Bravo
wrote:
> mov [bx],cl ;cl not cx
> inc cx
> inc bx ;bump the pointer
After some trial and error I found out how to accomplish what
I was looking for with help from another post in this thread. How to
use cx as an offset into state, rather than just increment the base
address. I was using the loop as a method of working with arrays, but
as your example above shows, offsets aren't always necessary. :)
Instead of the three lines above:
mov si,cx ;move offset into si
mov [bx+si],cl ;memory[bx+si] = cx
inc cx ;cx = cx + 1
I found it interesting that both examples created the same amount of
code.
I was using a slighly larger example to test one of the elements in
the array to see if it was correct. Rather than loop and increment up
to the desired element I wanted to find a way to use cx as an offset
into the array.
Many thanks to everyone who responded! My completed first program
is below.
Best Wishes,
Johnny Bravo
org 100h
section .data
msg1 db 'Correct!', 13, 10, '$'
msg2 db 'Incorrect!', 13, 10, '$'
section .bss
state resb 256
section .text
;initialize the loop and
;find the base of of the array
mov cx,0 ;cx = 0
mov bx,state ;bx = base address of state
aloop: ;set elements
mov si,cx ;move cx into si for offset
mov [bx+si],cl ;memory[bx+offset] = cx.
inc cx ;cx = cx + 1
cmp cx,256 ;if cx - 256 == 0 set zero flag
jnz aloop ;if zero flag not set jump to aloop
;test an element to see if it
;is holding the correct value
mov ax,127 ;picked an element to test
mov si,ax ;set offset
cmp [bx+si],al ;compare base+offset to test
jne fail
; If correct value, print "Correct!"
mov dx,msg1 ; move message to prepare for printing
mov ah,9 ; "print screen" function for int 21h
int 021h ; call DOS
jmp exit ; go to program exit
fail: ; If not value, print "Incorrect!"
mov dx,msg2 ; move message to prepare for printing
mov ah,9 ; "print screen" function for int 21h
int 021h ; call DOS
exit:
mov ah,04Ch ; terminate-program function
int 021h ; call DOS
John Casey
Advanced programmers aren't alway the best teachers
because they try to explain too much too soon or
assume that certain concepts are obvious.
The standard use of xor to clear registers can be
introduced as soon as the xor instruction is explained.
Don't think I don't appreciate it when advanced
programmers such as yourself give some good advice
and elegant solutions to a problem such as the
one below. I do agree learning and using advanced
techniques is part of using assembler.
I get a kick out of programming in assembler even
if I'm not very good at it. You don't have to be
a professional sports person to enjoy sport.
Regards,
John Casey.
John S. Fine wrote:
>
> [snip]
> Here is my simplified version of the sample program you have
> been discussing
>
> org 100h
> section .bss
> state resb 256
> section .text
Johnny Bravo
wrote:
> Be careful of one very important difference. In C,
>when you add an index (an integer) to a pointer, the
>compiler automatically multiplies the index by the
>size of the object pointed to. So if X[] is an
>array of short integers X[5] is the integer starting
>at byte offset 10 relative to X. If X[] were long
>integers then it would be offset 20.
Thanks, I also picked that up from The Art of Assembly,
and from a few examples I've seen on the net. Constantly
being reminded of it will prevent me from an afternoon of
confusion because I forgot, so thanks in advance! :)
> mov ebx,5
> mov ax,[X+ebx*2]
>
>This gets element 5; But using 32 bit registers in 16
>bit mode may be slow and this method doesn't work with
>16 bit registers.
It was a frustrating three days where I was trying
to use [x+cx] as an index and failing very badly.
>> I see what I was doing incorrectly. I was trying to access
>> state+offset directly in the mov instruction. [state+offset],
>> rather than [pointer+offset].
>
> Actually, that wasn't your error. You can have an array name
>as the constant part of an address and the index as the register
>part of the address. You just are limited in which register you
>use. You tried it with CX. You can do it with BX, SI or DI.
Another poster pointed out SI and DI. I got it working at last.
Thanks for letting me know about BX. I was using CX as it was part
of the loop command, had I started with BX it would have been much
easier but I wouldn't have learned nearly as much.
> xor bx,bx
Thanks, always glad to save a byte.
>Because 265 has a low byte of zero, I used "inc bl" instead
>of both the "inc bx" and the "cmp bx,256". I know that is a
>little advanced for beginners, but if you don't want to start
>thinking of things like that, you would be better off coding in
>C.
I understand it, but I'll learn to walk before I learn to run. :)
Thank you very much for your reply.
Best Wishes,
Johnny Bravo