How does NASM handle numbers.?
holyc...@hotmail.com
need to know because I don't want to have to convert from hex to
decimal or binary to decimal..
TB
what?
TB
<holyc...@hotmail.com> wrote in message
news:3fe7a1a4.02072...@posting.google.com...
Chewy509
<holyc...@hotmail.com> wrote in message...
> How does NASM handle hexadecimal , binary, and octal numbers? I really
> need to know because I don't want to have to convert from hex to
> decimal or binary to decimal..
>
Default is decimal, or to select:
hex by adding h at end (ie 0edh)
bin by adding b at end (ie 010101b)
oct by adding o at end (ie 123o)
dec by adding d at end (ie 123d)
If using a override ensure that the 1st char is a number, ie 0deh, or it
will treat it as a label.
Chewy509...
holyc...@hotmail.com
is hex, binary, or octal?
"TB" <NO_acr872k_SPAM@HERE_hotmail.com> wrote in message news:<DCF09.15837$LP1.7...@wagner.videotron.net>...
Frank Kotler
And you shouldn't have to! All numbers have to start with a decimal
digit (and identifiers must *not* start with a decimal digit). Decimal
is "just plain":
1234
Hex can be done as:
0xABC
0ABCh
or
$0ABC
Octal:
123q
It has been suggested that Nasm allow "123o" also for compatibility with
other assemblers, but it hasn't been done yet. (likewise "123t" for
decimal)
Binary:
1101b
(all case insensitive - allowing an uppercase 'o' for octal would be a
bad idea, IMO)
Best,
Frank
holyc...@hotmail.com
How does it differ from something like "dd" or "dq" or "dw" or "db"?
Frank Kotler <fbko...@attbi.com> wrote in message news:<3D45D385...@attbi.com>...
Orlando Llanes
> Could you possibly give a small app utilizing h, q, and b suffixes?
If you use BIOS services, you'll constantly deal with hexadecimal
constants, one example is...
mov ax, 13h
int 10h
xor ax, ax
int 16h
mov ax, 3
int 10h
mov ax, 4C00h
int 21h
What this does is change the screen mode to 320x200x256, then waits for
a keypress, then changes the screen mode back to 80x25 text, and finally
exits the program "the right way" :P
The last character influences the way the number is processed by the
assembler. You don't need the d suffix because it's the default. I never use
the octal suffix, I'm sure hardly anybody else does either, BUT it is
entirely possible that someone out there uses it.
The digits for the suffix d are 0..9. This is one is obvious so I won't
explain it because it's the number system we use every day. If I'm not
mistaken, the d suffix is present because you can change the number system
(radix? base?) with certain assemblers. In the case of Nasm (and NBasm?), I
don't think you'll need it at all.
The digits for the suffix h are 0..9 and A..F. Which means the following...
Decimal
0..9
10..15
Hex
0..9
A..F
The digits for the suffix q are 0..7. Which means the following...
Decimal
0..7
8..15
Octal
0..7
10..17
The digits for suffix b are 0 and 1. Which means the following...
Decimal
0
1
2
3
4
Binary
0b
1b
10b
11b
10b
> How does it differ from something like "dd" or "dq" or "dw" or "db"?
dd inserts a 32-bit double word, dq inserts a 64-bit quad word, dw
inserts a 16-bit word, and db inserts an 8-bit byte into your code. These
are NOT suffixes, these are compiler instructions. They tell the assembler
to convert the value into binary and directly insert it into your code.
Since you don't know what even db means, you should read more about
assembly language. An excellent book is The Art of Assembler is located
at...
See ya!
Orlando
Frank Kotler
>
> Could you possibly give a small app utilizing h, q, and b suffixes?
> How does it differ from something like "dd" or "dq" or "dw" or "db"?
; nasm -f bin -o prog.com prog.asm
org 100000000b
mov ah, 11q
mov dx, msg
int 00100001b
mov ah, 01001100b
int 41q
msg db 'hello world', 0Dh, 12q, 24h
I'm too lazy to do 'hello world' in some cryptic notation :)
The db, dw, dd, dq, and dt pseudo-instructions tell Nasm what size
number to emit into the codestream.
db 1 -> 01
dw 1 -> 01 00
dd 1 -> 01 00 00 00
They correspond to "byte", "word", "dword", "qword", and "tword" - used
to inform Nasm of the variable size in instructions where it's not
obvious from a register being used.
For example, "add [somevar], eax" doesn't require a size specifier, but
if you try "add [somevar], 3" Nasm will complain about "operation size
not specified" - you'll need to tell it "add dword [somevar], 3". Other
assemblers keep track of the fact that you've defined the variable as
"somevar dd 1234" - they'll do "add somevar, 3" without complaint - but
*will* complain if you try to do "mov somevar, al", since it's the wrong
size. Whether this is a "shortcoming" or a "feature" of Nasm is a matter
of opinion, I guess.
The h, q, and b suffixes (suffices?) do what you asked for - inform Nasm
of the "base" or "radix" you intend, so you don't have to convert
"0ABCDh" to "43981" or vice versa. You can write the number in whatever
representation you've "got" it in, and Nasm will do the "conversion".
Somewhat related to these suffixes (and the other methods of specifying
"base" - "0x..." and "$...") is the fact that the existance of a decimal
point indicates a floating point number. "myvar dd 1" is assembled as 01
00 00 00 (little-endian, remember). "myvar dd 1.0" assembles as 00 00 80
3F (represented here as hex, of course), which is the floating point
representation of "1.0". Note that dq and dt are for floating point
values *only* (at the moment) - "myvar dq 1" is a syntax error. Some
consideration is being given to changing this, since an "integer" dq
makes sense with some of the new instructions.
One place you can find the Nasm docs on line - fairly recent version -
is:
http://home.attbi.com/~fbkotler/nasmdoc0.html
Or download the very latest from:
Sorry to say, nasm.2y.net is no more - another victim of the
disappearing free web-space bug.
Best,
Frank
Grief
?????????:ai0dp9$1032g4$1...@ID-98691.news.dfncis.de...
>
> <holyc...@hotmail.com> wrote in message...
> > How does NASM handle hexadecimal , binary, and octal numbers? I really
> > need to know because I don't want to have to convert from hex to
> > decimal or binary to decimal..
> >
>
> Default is decimal, or to select:
> hex by adding h at end (ie 0edh)
nasm also understands 0xFF (like in C) and $0FF (like in Pascal, "0"-
required) formats for hex numbers
> bin by adding b at end (ie 010101b)
> oct by adding o at end (ie 123o)
> dec by adding d at end (ie 123d)
my nasm (v 0.98) does not recognize "123o" and "123d" formats (may be my
fault). i presume decimals are written simply "123" and octals like "123q"
Chewy509
"Grief" wrote in message...
> > Default is decimal, or to select:
> > hex by adding h at end (ie 0edh)
>
> nasm also understands 0xFF (like in C) and $0FF (like in Pascal, "0"-
> required) formats for hex numbers
Quite correct, but I like to keep a standard format (and for me it's adding
the 'h' at the end)...
>
> > bin by adding b at end (ie 010101b)
> > oct by adding o at end (ie 123o)
> > dec by adding d at end (ie 123d)
>
> my nasm (v 0.98) does not recognize "123o" and "123d" formats (may be my
> fault). i presume decimals are written simply "123" and octals like "123q"
After rereading my nasm manual I stand corrected on the oct postfix (should
be q instead of o)...
Chewy509...