NASM warning: "signed byte value exceeds bounds"
Chris Giese
push byte 0FFh
and also by push byte 80h, push byte 81h etc.
How can I supress it?
I want NASM to generate the short PUSH instruction (opcode 6Ah).
I am using 32-bit code.
Thanks in advance.
--
geezer@ | http://www.execpc.com/~geezer
execpc.com | http://www.execpc.com/~geezer/osd
Grzegorz Mazur
news:3c56139d$0$35622$272e...@news.execpc.com...
> This warning is generated by this instruction:
>
> push byte 0FFh
>
> and also by push byte 80h, push byte 81h etc.
> How can I supress it?
>
> I want NASM to generate the short PUSH instruction (opcode 6Ah).
> I am using 32-bit code.
If the constant in question is supposed to be sign-extended, use:
push byte -1
push byte -128
The values pushed will be 0xF..FFF and 0xF..F80.
If you want to push 255 or 128, you must use long form of push immediate, as
8-bit values are always sign extended to 16/32 bits before pushing.
Martin Kiewitz
wrote:
> This warning is generated by this instruction:
> push byte 0FFh
> and also by push byte 80h, push byte 81h etc.
> How can I supress it?
First, PLEASE buy yourself an assembly book and learn what the stack
is or don't use assembly.
The answer: use "Push 0FFh", without byte.
cu, Kiewitz
--
Randall Hyde
Grzegorz Mazur wrote in message ...
Hmmm....
This is a case of NASM's syntax getting in the way of the job.
As an assembly language programmer, I *know* that I can
push 255 onto the stack; I *don't* have to push it as a long
form. Changing the constant to "-1" to satisfy NASM when
I'm actually pushing an unsigned value seems to be a pain.
Yes, I do realize that the value 0xFF...FF is really being pushed
on the stack, but if I only access the L.O. byte from my
code (e.g., it's a parameter I'm passing), then it seems to
me that there should be some way to tell NASM that I
don't care what happens with the upper byte(s) so I can
state my code more clearly.
Not that any of the other assemblers support this, but
NASM proponents make such a big deal about the
assembler doing "exactly what I tell it to" that this seems
to be a problem that should be corrected.
Randy Hyde
debs
On Tue, 29 Jan 2002 20:16:16 +0000 (UTC), Martin Kiewitz spake thus:
The Intel documentation clearly states that there are two separate
instructions for pushing immediate values:
instr. opcode
push imm8 6A imm8
push imm16 o16 68 imm16
push imm32 o32 68 imm32
What it doesn't clearly show is that the push imm8 form takes a signed
byte and sign extends it fill the appropriate operand size before
pushing. I only found that by looking at the opcode encoding appendix
in the appropriate volume (IA developer manual, vol 2). Not everyone
knows that there is additional information about instructions included
in the appendices, when every instruction has at least one full page
for it's description in the chapter which is dedicated to describing
them.
If the OP wanted to push 255, then it would have to be pushed as a
word or dword, but as the docs are so vague then I think it's unfair
to tell him to look it up without an explanation. I looked through
several documents and books before posting this reply, and the only
place I found any reference to the push imm8 taking a signed byte and
extending it was in an appendix of one of the Intel docs - not the
first place most people will look to find out how an instruction works
- so I think it's a fair mistake for anyone to make the first time
they come across it.
--
debs
de...@dwiles.nospam.demon.co.uk
----
Misspelled? Impossible! I have an error correcting modem.
Frank Kotler
That'll generate 68 FF 00 - Chris was clear that he wanted 6A FF - which
he's getting (right?), but with an undesired warning (not suppressable,
maybe it should be) from Nasm.
Grzegorz had the right answer, I think - use "-1" or whatever. Or just
ignore the damn warning :)
Best,
Frank
Chris Giese
>On Tue, 29 Jan 2002 03:55:52 UTC, NoEma...@execpc.com (Chris Giese)
>wrote:
>
>> This warning is generated by this instruction:
>> push byte 0FFh
>> and also by push byte 80h, push byte 81h etc.
>> How can I supress it?
>
>First, PLEASE buy yourself an assembly book and learn what the stack
>is or don't use assembly.
I know how to use asm and I know what a stack is, you patronizing
asshole.
>The answer: use "Push 0FFh", without byte.
Did you even try it? Because it won't assemble:
BITS 32
push 0FFh
C:\>nasm -f bin foo.asm
foo.asm:2: operation size not specified
It works under TASM, but produces the long form of the PUSH
instruction (4-byte operand):
C:\>ndisasm -u foo.bin
00000000 68FF000000 push dword 0xff
Never mind. I'll use a macro to fix it.
Frank Kotler
Nasm *does* do exactly what you tell it. It just warns you that the
operand you've given, in the form you've given it, exceeds signed-byte
range. You may know that you're going to treat it as unsigned, but it's
still being sign-extended. You don't *need* to use "-1", except to
assure Nasm that you know what you're doing. This *is* contrary to
Nasm's usual assumption that you *do* know what you're doing, but it's
an idiosyncrasy, not a bug :)
I think all Chris wanted was a way to suppress the warning, as you can
with several other warnings that Nasm emits (if you tell it to). Look
for it in Nasm 2.0, Chris - I haven't even got 'em to look at your
outelf.c yet...
Best,
Frank
Martin Kiewitz
> >First, PLEASE buy yourself an assembly book and learn what the stack
> >is or don't use assembly.
> >The answer: use "Push 0FFh", without byte.
> The Intel documentation clearly states that there are two separate
> instructions for pushing immediate values:
That's right.
But those are used automatically by the assembler.
If you specify BYTE in front of, the assembler thinks you want to push
a BYTE and that's actually impossible.
The PUSH BYTE opcode just uses 8-bit for actually pushing a 16-bit
value to stack. It's just saving one byte, when not needed, but it's
not pushing a byte, it's pushing a word.
> If the OP wanted to push 255, then it would have to be pushed as a
It will use a WORD for it, that's why the assembler gets confused by
the PUSH BYTE XXX instruction.
That's why I said that one should buy an assembly book before using
assembly.
> - so I think it's a fair mistake for anyone to make the first time
> they come across it.
You find that everywhere. Just get yourself informed, before trying to
do such critical work. If you don't want to, simply use C or some
other language, but please not assembly.
Stack on x86 is WORD-based. You will never find any stack that is able
to push bytes.
cu, Kiewitz
--
Martin Kiewitz
<fbko...@ne.mediaone.net> wrote:
> > First, PLEASE buy yourself an assembly book and learn what the stack
> > is or don't use assembly.
> > The answer: use "Push 0FFh", without byte.
> That'll generate 68 FF 00 - Chris was clear that he wanted 6A FF - which
no.
> he's getting (right?), but with an undesired warning (not suppressable,
> maybe it should be) from Nasm.
actually no. Any assembler will automatically use the best opcode for
that job.
PUSH byte would mean that one would want to "actually" push a byte to
stack and that's impossible.
> Grzegorz had the right answer, I think - use "-1" or whatever. Or just
> ignore the damn warning :)
If you think so. Using "Push byte" is just fault, but "recoverable",
that's why the warning comes up.
cu, Kiewitz
--
Frank Kotler
>
> On Wed, 30 Jan 2002 02:55:57 UTC, Frank Kotler
> <fbko...@ne.mediaone.net> wrote:
>
> > > First, PLEASE buy yourself an assembly book and learn what the stack
> > > is or don't use assembly.
> > > The answer: use "Push 0FFh", without byte.
> > That'll generate 68 FF 00 - Chris was clear that he wanted 6A FF - which
>
> no.
No, what? No that's not what Chris wanted, or no that's not what Nasm's
giving him? I can't be sure what Chris wanted (tho that's what he said),
but I assure you that that *is* what Nasm will do. (okay, that's 16-bit
code - Chris said 32-bit, so 68 FF 00 00 00 ...)
> > he's getting (right?), but with an undesired warning (not suppressable,
> > maybe it should be) from Nasm.
>
> actually no. Any assembler will automatically use the best opcode for
> that job.
If by "any assembler", you mean "all assemblers", I have to disagree
again. If you mean "some assembler" will do this, okay, which one did
you have in mind?
> PUSH byte would mean that one would want to "actually" push a byte to
> stack and that's impossible.
Well, I agree that actually pushing just a single byte is impossible (of
course), but what "push byte" means depends on the assembler. In Nasm
syntax, it will do exactly what (I think) Chris wants - 6A FF. It's just
that if you express the operand as "0FFh" rather than "-1", Nasm warns
you...
> > Grzegorz had the right answer, I think - use "-1" or whatever. Or just
> > ignore the damn warning :)
>
> If you think so. Using "Push byte" is just fault, but "recoverable",
> that's why the warning comes up.
I *do* think so, yes! It may be that "push byte" is a "fault" in some
assemblers' syntax, but it's correct for Nasm. I personally feel that
it's reasonable for Nasm to generate the warning, but I agree with Chris
that it should be suppressable (and maybe even "off" by default ???). In
spite of the warning, Nasm *is* generating 6A FF, as desired.
Which assembler is it you think one should buy a book on, or "not use
assembly"? You *do* realize they're not all the same, right?
Best,
Frank
Martin Kiewitz
wrote:
> >First, PLEASE buy yourself an assembly book and learn what the stack
> >is or don't use assembly.
> I know how to use asm and I know what a stack is, you patronizing
> asshole.
nice and friendly way you got.
Actually you don't know what a stack is, otherwise you wouldn't use
"push byte 0FFh".
You know, stacks are built up of at least words.
for example: There is no PUSH AL, POP AL instruction. Interresting
isn't it.
Like I said, buy yourself an assembly book.
> >The answer: use "Push 0FFh", without byte.
> Did you even try it? Because it won't assemble:
I'm using it in Real-mode programs several times.
> BITS 32
> push 0FFh
Kill that BITS 32 line and off you go.
> C:\>nasm -f bin foo.asm
> foo.asm:2: operation size not specified
> It works under TASM, but produces the long form of the PUSH
> instruction (4-byte operand):
If you tell the assembler to use 32 bits, don't ask yourself why it
actually does what you wanted.
Please go buy an assembly book or use another language. Assembly is
not for wannabes.
cu, Kiewitz
--
Randall Hyde
Frank Kotler wrote in message
>Nasm *does* do exactly what you tell it. It just warns you that the
>operand you've given, in the form you've given it, exceeds signed-byte
>range. You may know that you're going to treat it as unsigned, but it's
>still being sign-extended. You don't *need* to use "-1", except to
>assure Nasm that you know what you're doing. This *is* contrary to
>Nasm's usual assumption that you *do* know what you're doing, but it's
>an idiosyncrasy, not a bug :)
>
>I think all Chris wanted was a way to suppress the warning, as you can
>with several other warnings that Nasm emits (if you tell it to). Look
>for it in Nasm 2.0, Chris - I haven't even got 'em to look at your
>outelf.c yet...
Well, that does make sense.
Perhaps a "as signed byte" type of prefix could be used to
shut up the warning and let the programmer specify exactly
what they mean.
Randy Hyde
Martin Kiewitz
<fbko...@ne.mediaone.net> wrote:
> > > > First, PLEASE buy yourself an assembly book and learn what the stack
> > > > is or don't use assembly.
> > > > The answer: use "Push 0FFh", without byte.
> > > That'll generate 68 FF 00 - Chris was clear that he wanted 6A FF - which
> > no.
> No, what? No that's not what Chris wanted, or no that's not what Nasm's
> giving him? I can't be sure what Chris wanted (tho that's what he said),
> but I assure you that that *is* what Nasm will do. (okay, that's 16-bit
> code - Chris said 32-bit, so 68 FF 00 00 00 ...)
Perhaps he included some nice BITS 32 or BITS 16 directive.
Nothing I can do about it.
He should LEARN the basics of assembly and the usage of an assembler.
Nasm is not a good-assembler anyway. He should try ALP, TASM or MASM.
> > > he's getting (right?), but with an undesired warning (not suppressable,
> > > maybe it should be) from Nasm.
> > actually no. Any assembler will automatically use the best opcode for
> > that job.
> If by "any assembler", you mean "all assemblers", I have to disagree
> again. If you mean "some assembler" will do this, okay, which one did
> you have in mind?
I'm using TASM for RealMode (16:16), ALP for Protected Mode (32:0) and
sometimes MASM, if I have to modify other commercial projects.
> > PUSH byte would mean that one would want to "actually" push a byte to
> > stack and that's impossible.
> Well, I agree that actually pushing just a single byte is impossible (of
> course),
nice.
> but what "push byte" means depends on the assembler. In Nasm
> syntax, it will do exactly what (I think) Chris wants - 6A FF. It's just
> that if you express the operand as "0FFh" rather than "-1", Nasm warns
> you...
0FFh is always considered as a unsigned variable. So why should it
warn you about it. (that's why the "0" is required, you can't specify
"FFh").
It's warning because of the byte directive and because it's impossible
to push bytes.
If he wants to specify every single opcode, then he should use
inline-assembly and a hex-editor. Assemblers do (normally) what they
are supposed to do.
> > > Grzegorz had the right answer, I think - use "-1" or whatever. Or just
> > > ignore the damn warning :)
> > If you think so. Using "Push byte" is just fault, but "recoverable",
> > that's why the warning comes up.
> I *do* think so, yes! It may be that "push byte" is a "fault" in some
> assemblers' syntax, but it's correct for Nasm. I personally feel that
If it's correct, then why does the warning come up ?
And what has this do to do with the syntax ? The syntax is correct,
but the logic isn't.
> it's reasonable for Nasm to generate the warning, but I agree with Chris
> that it should be suppressable (and maybe even "off" by default ???). In
> spite of the warning, Nasm *is* generating 6A FF, as desired.
Actually, NO, because PUSH BYTE [value] is NOT correct. Get it ?
PUSH DWORD would be correct, because the command would push the value
as DWORD to stack.
PUSH WORD would be correct, because the command would push the value
as WORD to the stack.
but
PUSH BYTE is INCORRECT, because it's not possible to push single bytes
to stack. That's the problem.
Push BYTE is not considered as "how-the-opcode-is-done", but "what the
value represents".
that's why you have to specify:
mov dx, word ptr [whateverpointer]
You can do:
PUSH WORD 77h -> for pushing the word 77h to the stack
or
PUSH DWORD 77h -> for doing a PUSHD (DWORD-Push) to stack
seems logical ? That's why PUSH BYTE is invalid and the warning is
absolutely correct. It's fixable, but it's invalid.
> Which assembler is it you think one should buy a book on, or "not use
> assembly"? You *do* realize they're not all the same, right?
I never found one book, where the stack was not explained. Simple as
that.
One of the problems, why assembly is considered as so "bad", is
because C programmers (or someone like that) "try" to do assembly,
without knowing what they are doing. Learning how to code in assembly
is not trivial and if you don't know how to do it, you should use
high-level language instead.
cu, Kiewitz
--
Martin Kiewitz
wrote:
> >I think all Chris wanted was a way to suppress the warning, as you can
> >with several other warnings that Nasm emits (if you tell it to). Look
> >for it in Nasm 2.0, Chris - I haven't even got 'em to look at your
> >outelf.c yet...
> Well, that does make sense.
> Perhaps a "as signed byte" type of prefix could be used to
> shut up the warning and let the programmer specify exactly
> what they mean.
[ ] You know that assemblers don't separate unsigned from signed
values. The programmer has to do it. (#1)
Argh, go back to writing C programs, PLEASE.
cu, Kiewitz
P.S.: #1 - That's why JA/JB and JG/JL opcodes exist.
--
Frank Kotler
>
> On Wed, 30 Jan 2002 16:56:42 UTC, Frank Kotler
> <fbko...@ne.mediaone.net> wrote:
>
> > > > > First, PLEASE buy yourself an assembly book and learn what the stack
> > > > > is or don't use assembly.
> > > > > The answer: use "Push 0FFh", without byte.
> > > > That'll generate 68 FF 00 - Chris was clear that he wanted 6A FF - which
> > > no.
> > No, what? No that's not what Chris wanted, or no that's not what Nasm's
> > giving him? I can't be sure what Chris wanted (tho that's what he said),
> > but I assure you that that *is* what Nasm will do. (okay, that's 16-bit
> > code - Chris said 32-bit, so 68 FF 00 00 00 ...)
>
> Perhaps he included some nice BITS 32 or BITS 16 directive.
Right, he did. Nasm defaults to 16 bit. Chris wanted 32-bit, so he
included the directive.
> Nothing I can do about it.
Who asked you to do anything about it?
> He should LEARN the basics of assembly and the usage of an assembler.
I don't know Chris personally, but I'm familiar enough with his work to
assure you he knows *exactly* what he's trying to do. All you've shown
me so far is that you've got a 32-bit ego in an 8-bit brain.
> Nasm is not a good-assembler anyway. He should try ALP, TASM or MASM.
I'm not familiar with ALP - if it requires a hex-editor to code 6A FF,
I'll pass.
> > > > he's getting (right?), but with an undesired warning (not suppressable,
> > > > maybe it should be) from Nasm.
> > > actually no. Any assembler will automatically use the best opcode for
> > > that job.
> > If by "any assembler", you mean "all assemblers", I have to disagree
> > again. If you mean "some assembler" will do this, okay, which one did
> > you have in mind?
>
> I'm using TASM for RealMode (16:16), ALP for Protected Mode (32:0) and
> sometimes MASM, if I have to modify other commercial projects.
So how do you get 6A FF out of these assemblers? You seem to be saying
that 68 FF 00 00 00 is the only way to do it.
> > > PUSH byte would mean that one would want to "actually" push a byte to
> > > stack and that's impossible.
> > Well, I agree that actually pushing just a single byte is impossible (of
> > course),
>
> nice.
>
> > but what "push byte" means depends on the assembler. In Nasm
> > syntax, it will do exactly what (I think) Chris wants - 6A FF. It's just
> > that if you express the operand as "0FFh" rather than "-1", Nasm warns
> > you...
>
> 0FFh is always considered as a unsigned variable. So why should it
> warn you about it. (that's why the "0" is required, you can't specify
> "FFh").
What book is it where you learned that the requirement for a leading
zero had anything to do with whether it's signed or unsigned???
> It's warning because of the byte directive and because it's impossible
> to push bytes.
Funny it doesn't warn on "push byte 1" or "push byte -1". You're the
only one who thinks anybody believes it actually going to push a single
byte. It's warning because the value given exceeds signed-byte range.
> If he wants to specify every single opcode, then he should use
> inline-assembly and a hex-editor. Assemblers do (normally) what they
> are supposed to do.
Sure, if you know how to tell it to do what you want. If you need a
hex-editor to do what you want, maybe you should consider a different
assembler?
> > > > Grzegorz had the right answer, I think - use "-1" or whatever. Or just
> > > > ignore the damn warning :)
> > > If you think so. Using "Push byte" is just fault, but "recoverable",
> > > that's why the warning comes up.
> > I *do* think so, yes! It may be that "push byte" is a "fault" in some
> > assemblers' syntax, but it's correct for Nasm. I personally feel that
>
> If it's correct, then why does the warning come up ?
Because the value given exceeds signed-byte range.
> And what has this do to do with the syntax ? The syntax is correct,
> but the logic isn't.
Apparently, "push byte" is incorrect syntax in the assemblers you're
familiar with.
Nothing wrong with the logic - even yours. You've assumed that Chris is
an idiot, and concluded that he's really trying to push just one byte.
It's the assumption that's broken, not the logic.
> > it's reasonable for Nasm to generate the warning, but I agree with Chris
> > that it should be suppressable (and maybe even "off" by default ???). In
> > spite of the warning, Nasm *is* generating 6A FF, as desired.
>
> Actually, NO, because PUSH BYTE [value] is NOT correct. Get it ?
No, I'm afraid I don't get it.
> PUSH DWORD would be correct, because the command would push the value
> as DWORD to stack.
Right, but not what we want.
> PUSH WORD would be correct, because the command would push the value
> as WORD to the stack.
Right, but not what we want.
> but
> PUSH BYTE is INCORRECT, because it's not possible to push single bytes
> to stack. That's the problem.
Wrong. "push byte" is perfectly valid Nasm syntax. We *know* it's going
to sign-extend our byte to word or dword, and push that. We want to use
only one byte in the codestream to to store our one-byte value - *not*
push only one byte. Maybe they left that chapter out of your book.
> Push BYTE is not considered as "how-the-opcode-is-done", but "what the
> value represents".
What?
> that's why you have to specify:
> mov dx, word ptr [whateverpointer]
No you don't. Nasm will barf on "ptr", and the "word" is optional - Nasm
knows what size dx is. I'm under the impression, tho less certain, that
just "mov dx, [whateverpointer]" is okay with Masm and Tasm, also. Dunno
'bout ALP.
> You can do:
> PUSH WORD 77h -> for pushing the word 77h to the stack
> or
> PUSH DWORD 77h -> for doing a PUSHD (DWORD-Push) to stack
And you can do "push byte 77h" (in the assembler under discussion). The
fact that you're unaware of it makes no difference to Nasm.
> seems logical ? That's why PUSH BYTE is invalid and the warning is
> absolutely correct. It's fixable, but it's invalid.
"push byte 77h" won't draw a warning, because it's within signed-byte
range.
> > Which assembler is it you think one should buy a book on, or "not use
> > assembly"? You *do* realize they're not all the same, right?
>
> I never found one book, where the stack was not explained. Simple as
> that.
> One of the problems, why assembly is considered as so "bad", is
> because C programmers (or someone like that) "try" to do assembly,
> without knowing what they are doing. Learning how to code in assembly
> is not trivial and if you don't know how to do it, you should use
> high-level language instead.
It appears that your book may have explained the stack and it's
instructions inadequately. You seem not to understand what it is that
we're talking about here. I agree that asm is not trivial, but I don't
think it's "bad" just because someone's opinion of their understanding
exceeds their understanding.
Best,
Frank
Randall Hyde
Martin Kiewitz wrote in message ...
>values. The programmer has to do it. (#1)
>
>Argh, go back to writing C programs, PLEASE.
>
>cu, Kiewitz
>
>P.S.: #1 - That's why JA/JB and JG/JL opcodes exist.
I truly believe you are confusing the x86 processors and
how they operate with how assemblers operate.
Many assemblers most assuredly differentiate signed and
unsigned values. MASM does. TASM does. HLA does.
I'd even suspect that NASM does in special cases
(e.g., operands that have sign extended immediate
operands). If I were you, I'd give up this argument.
It really seems that with each new post you keep putting
your foot in your mouth.
Randy Hyde
P.S. #2: why do you think that sbyte, sword, and sdword
exist in MASM/TASM? Why do you think int8, int16, and
int32 exist in HLA (versus uns8, uns16, and uns32)?
Martin Kiewitz
wrote:
> >[ ] You know that assemblers don't separate unsigned from signed
> >values. The programmer has to do it. (#1)
> >Argh, go back to writing C programs, PLEASE.
> >cu, Kiewitz
> >P.S.: #1 - That's why JA/JB and JG/JL opcodes exist.
> I truly believe you are confusing the x86 processors and
> how they operate with how assemblers operate.
> Many assemblers most assuredly differentiate signed and
> unsigned values. MASM does. TASM does. HLA does.
MASM does not. TASM does not.
Tell me how to specify an unsigned byte and a signed byte.
I'm really interrested in knowing it.
> P.S. #2: why do you think that sbyte, sword, and sdword
> exist in MASM/TASM? Why do you think int8, int16, and
> int32 exist in HLA (versus uns8, uns16, and uns32)?
And what should the assembler do with that information ?
You know, those bad-boy conditional jumps must be written by hand aka
JA/JB, JL/JG.
So what to put there, so that the assembler will "automagically"
convert it to the correct one ? (JA/JB is unsigned and JL/JG is
signed, JE/JNE is equal/not equal, JC/JNC is for carry-flag. So where
is your "freakin" special opcode that gets transfered to the correct
one ?)
cu, Kiewitz
--
Martin Kiewitz
<fbko...@ne.mediaone.net> wrote:
> > > No, what? No that's not what Chris wanted, or no that's not what Nasm's
> > > giving him? I can't be sure what Chris wanted (tho that's what he said),
> > > but I assure you that that *is* what Nasm will do. (okay, that's 16-bit
> > > code - Chris said 32-bit, so 68 FF 00 00 00 ...)
> > Perhaps he included some nice BITS 32 or BITS 16 directive.
> Right, he did. Nasm defaults to 16 bit. Chris wanted 32-bit, so he
> included the directive.
So why does he complain, because the assembler does it, like he told
it to ?
If you press Ctrl-Alt-Del, yes, your computer will reboot (under some
OS at least). So what ? It's doing what you are telling it to do.
> > He should LEARN the basics of assembly and the usage of an assembler.
> I don't know Chris personally, but I'm familiar enough with his work to
> assure you he knows *exactly* what he's trying to do. All you've shown
exactly...NO.
> me so far is that you've got a 32-bit ego in an 8-bit brain.
loool.
I would say 64-bit brain and a 32-bit ego.
> > Nasm is not a good-assembler anyway. He should try ALP, TASM or MASM.
> I'm not familiar with ALP - if it requires a hex-editor to code 6A FF,
> I'll pass.
You can simply
db 6A, 0FFh
done. Where is the f*cking problem ?
Go back to your beloved C. PLEASE. Go C. That's the way at least you
are somehow experienced in.
> > I'm using TASM for RealMode (16:16), ALP for Protected Mode (32:0) and
> > sometimes MASM, if I have to modify other commercial projects.
> So how do you get 6A FF out of these assemblers? You seem to be saying
db 6A, 0FFh
If I want a specific opcode, I code it by myself.
> that 68 FF 00 00 00 is the only way to do it.
He wanted 32-bits. So why does he complain the whole time ?
Enter FORMAT C:. Then press Y. Oh, damn, the stupid computer just
formatted the harddrive.
> > 0FFh is always considered as a unsigned variable. So why should it
> > warn you about it. (that's why the "0" is required, you can't specify
> > "FFh").
> What book is it where you learned that the requirement for a leading
> zero had anything to do with whether it's signed or unsigned???
It does.
Go buy an assembly book.
> > It's warning because of the byte directive and because it's impossible
> > to push bytes.
> Funny it doesn't warn on "push byte 1" or "push byte -1". You're the
> only one who thinks anybody believes it actually going to push a single
> byte. It's warning because the value given exceeds signed-byte range.
Then 0FFh should fix it. But it does not.
> > If he wants to specify every single opcode, then he should use
> > inline-assembly and a hex-editor. Assemblers do (normally) what they
> > are supposed to do.
> Sure, if you know how to tell it to do what you want. If you need a
> hex-editor to do what you want, maybe you should consider a different
> assembler?
If he would know how to specify data in a code-segment or even data
anywhere, then he would automatically know how to specify special
opcodes.
That's how most assembly coders specify CPUID, because it's almost
unsupported anywhere.
> > If it's correct, then why does the warning come up ?
> Because the value given exceeds signed-byte range.
No.
Specifying FFh would be bad. 0FFh is correct.
> > And what has this do to do with the syntax ? The syntax is correct,
> > but the logic isn't.
> Apparently, "push byte" is incorrect syntax in the assemblers you're
> familiar with.
Yeah whatever.
"push byte" is correct SYNTAX, you damn idiot.
> Nothing wrong with the logic - even yours. You've assumed that Chris is
> an idiot, and concluded that he's really trying to push just one byte.
> It's the assumption that's broken, not the logic.
the syntax is correct, you get it ?
> > but
> > PUSH BYTE is INCORRECT, because it's not possible to push single bytes
> > to stack. That's the problem.
> Wrong. "push byte" is perfectly valid Nasm syntax. We *know* it's going
And about that warning ? It's just there for fun ey ?
> to sign-extend our byte to word or dword, and push that. We want to use
How should it SIGN your BYTE to WORD ?
Argh
YOU ARE AN ABSOLUTE IDIOT. You don't know shit about assembly. Go back
to your C.
The *opcode* he wants uses just a BYTE for data. That's all. It won't
sign/unsign or do anything. And it's just an opcode. It will actually
push a WORD to the stack, but it won't nul out the upper byte of the
WORD.
Get it ?
> only one byte in the codestream to to store our one-byte value - *not*
> push only one byte. Maybe they left that chapter out of your book.
[ ] You know much about signed and unsigned values under assembly
> > Push BYTE is not considered as "how-the-opcode-is-done", but "what the
> > value represents".
> What?
Yes, you are a total idiot.
> > that's why you have to specify:
> > mov dx, word ptr [whateverpointer]
> No you don't. Nasm will barf on "ptr", and the "word" is optional - Nasm
> knows what size dx is. I'm under the impression, tho less certain, that
on:
Whateverpointer db "Fuck This stupid idiot in here", 0
mov dx, word ptr [whateverpointer]
IT IS FUCKING REQUIRED. Otherwise the assembler would not be able to
check your dumbo coding.
> just "mov dx, [whateverpointer]" is okay with Masm and Tasm, also. Dunno
> 'bout ALP.
actually not. You will get a warning, you know if whateverpointer is
not defined as word or something.
> And you can do "push byte 77h" (in the assembler under discussion). The
actually no.
Because you can't push a single byte to stack.
cu, Kiewitz
--
Randall Hyde
Martin Kiewitz wrote in message ...
>wrote:
>
>> >[ ] You know that assemblers don't separate unsigned from signed
>> >values. The programmer has to do it. (#1)
>> >Argh, go back to writing C programs, PLEASE.
>> >cu, Kiewitz
>> >P.S.: #1 - That's why JA/JB and JG/JL opcodes exist.
>> I truly believe you are confusing the x86 processors and
>> how they operate with how assemblers operate.
>> Many assemblers most assuredly differentiate signed and
>> unsigned values. MASM does. TASM does. HLA does.
>
>MASM does not. TASM does not.
Okay, you are ignorant of MASM 6.x and TASM 5.x.
But your ignorance doesn't change the fact that these
assemblers provide support for signed versus unsigned
variables.
>
>Tell me how to specify an unsigned byte and a signed byte.
>I'm really interrested in knowing it.
MASM (and TASM):
signedInt32 sdword ?
signedInt16 sword ?
signedInt8 sbyte ?
>
>> P.S. #2: why do you think that sbyte, sword, and sdword
>> exist in MASM/TASM? Why do you think int8, int16, and
>> int32 exist in HLA (versus uns8, uns16, and uns32)?
>
>And what should the assembler do with that information ?
>You know, those bad-boy conditional jumps must be written by hand aka
>JA/JB, JL/JG.
The assembler passes this information along to the debugger
so that it can display the data in it's native format.
It's still the programmer's responsibility to use the appropriate
instuction with regard to these operands (e.g., JA vs JG, MUL vs IMUL).
>So what to put there, so that the assembler will "automagically"
>convert it to the correct one ? (JA/JB is unsigned and JL/JG is
>signed, JE/JNE is equal/not equal, JC/JNC is for carry-flag. So where
>is your "freakin" special opcode that gets transfered to the correct
>one ?)
Once again, you are confusing *assembly* language with *machine*
language. The x86 architecture (any twos-complement architecture,
actually), doesn't differentiate between signed and unsigned
integer data in memory. The programmer has to use explicit
instructions to do so (as you continually point out). However,
that doesn't mean that the assembler can't differentiate the two
as a means of making the code easier to read, catching logical
errors that sneak into programs (e.g., attempting to use
a signed byte operand that is too large for the PUSH instruction),
and even doing reasonable type checking during constant
expression evaluation.
The whole point of this thread, which you seem too dense to
comprehend, is that NASM is doing the programmer a favor
by warning that a signed byte operand to the PUSH instruction
is out of range. The original complaint (which seems to have
gone completely over your head) is that the programmer
knows exactly what he's doing and as far as the *machine*
code is concerned, the instruction he's supplying is perfectly
legal. NASM even generates the appropriate machine code.
The original poster simply wanted to eliminate the error message.
You've turned this into a "you can't do that" tirade, which many
people have pointed out over and over again that "yes, you
can do that." Even the original poster pointed out that he
knows exactly what he's doing and understands the implication,
and it's exactly what he wants to have happen. Your response?
Accuse him of being a "C programmer who should learn
assembly."
Now, perhaps you feel that the original poster should use the
constant "-1" rather than 0FFh in order to shut up the assembler.
However, if the original programmer was actually pushing
an unsigned byte on the stack, and he wanted to indicate
this in his code by putting 0FFh rather than "-1" (which
indicates the use of a signed value to the reader), I certainly
applaud him for trying to write readable assembly code
rather than falling back to cryptic signed data representations
of unsigned values.
Please don't go back into the tirade about not being able
to push bytes onto the stack. *Everyone* here knows that
you can't push bytes with a single instruction. However,
my guess is that the original poster wanted to push a byte
value (perhaps as a byte parameter) AND DOESN'T CARE
WHAT VALUE THE H.O. BYTE(S) OF THE PUSHED VALUE
CONTAIN. Whether the PUSH instruction sign extends to
all ones or zero/sign extends to all zeros is quite possibly
irrelevant if the program never accesses those bytes.
You, however, seem to feel that the programmer *must* use
the longer form of the PUSH immediate instruction if
he wants to push 0FFh on the stack. This demonstrates
that the original poster knows assembly language
*much* better than you do, despite your claims of his
ignorance.
Forgive me for being a little harse, but you seem to be
incredibly dense and just don't get it. How much plainer
can people state the problem?
Randy Hyde
Frank Kotler
> Because you can't push a single byte to stack.
Ah! Okay, I see. Thanks for clearing that up for me.
Best,
Frank
Frank Kotler
>
> This warning is generated by this instruction:
>
> push byte 0FFh
>
> and also by push byte 80h, push byte 81h etc.
> How can I supress it?
Well, "standard Nasm" doesn't have this on it's list of suppressible
warnings. I've sent you a proposed patch to add it, then you can do
"-w-sbyte-overflow" and Nasm will shut up about it. Don't forget to use
the leading zero on "0FFh" or it won't be signed :)
Extreme caution should be exercised to only use this with "assembly
language", and not with the similarly named (but apparenly quite
different) "assembly language", which a Mr. Kiewitz apparently owns.
Best,
Frank
Ka-Chi CHEUNG
On Thu, 31 Jan 2002, Martin Kiewitz wrote:
>
> > > 0FFh is always considered as a unsigned variable. So why should it
> > > warn you about it. (that's why the "0" is required, you can't specify
> > > "FFh").
> > What book is it where you learned that the requirement for a leading
> > zero had anything to do with whether it's signed or unsigned???
>
> It does.
> Go buy an assembly book.
You shot yourself in the foot again. I don't know what assembly book you
have, but I certainly would *not* recommend it to anyone if it claims that
the reason for 0FFh rather than FFh is that it is an unsigned number. The
real reason for the leading "0" has to do with the parsing of a number
rather than any type information. A number is defined in assembly (MASM
Specification, and I guess others as well), as a decimal digit followed by
hex or dec digits. If you don't believe me, try reading up the actual
grammar for MASM.
decdigit 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
hexdigit a | b | c | d | e | f | A | B | C | D | E | F
digits decdigit
| digits decdigit
| digits hexdigit
constant digits [radixOveride]
radixOveride h | o | q | t | y | H | O | Q | T | Y
so FFh is NOT a number...which is why you have to put a leading 0 to make
it a number. It has absolutely jack all to do with signed and unsigned
number
If you do have a 64-bit brain, then the reason for this should be quite
apparent, and you could not have truly believed in the so called book of
yours....
Now, I can certainly only speak of MASM. I truly don't know how other
assemblers implement their numbers, but given the unique nature of
parsing, I would suspect they are all the same. It would be terribly
inefficient for the parser to tell the difference between FFh as a number
and FFh as an identifier.
> > > If it's correct, then why does the warning come up ?
> > Because the value given exceeds signed-byte range.
>
> No.
> Specifying FFh would be bad. 0FFh is correct.
>
FFh is not a number....it's an identifier, which is why it's
incorrect.
Yours,
Ka-Chi
debs
On Wed, 30 Jan 2002 20:55:57 +0000 (UTC), Martin Kiewitz spake thus:
My last few posts havent got through (I think it's a problem with my
news server), so I'm resending this one and ccing it to the email
address. I'll leave the others, coz they all relate to the same topic,
and this one includes the Intel references that relate to the topic at
hand....
>Perhaps he included some nice BITS 32 or BITS 16 directive.
>Nothing I can do about it.
>He should LEARN the basics of assembly and the usage of an assembler.
Perhaps you should learn what the processor is capable of.
>
>Nasm is not a good-assembler anyway. He should try ALP, TASM or MASM.
NASM is a great assembler. It's free, it's open source, it supports
all instructions up to the latest x86 instruction sets..... It's also
always assembled any valid x86 code that I've passed to it. I'm yet to
see a boot sector written in another assembler that can do everything
my boot sector can do plus more. If nasm is so bad, how come it can do
things as well as others (in fact, there are things you can't do in
masm that you can do in nasm, and which the Intel processor docs say
you can do). Nasm will also allow you to assemble code without having
to know all the assembler directives that you need for masm. With
nasm, you can take code directly out of the Intel manuals, and in most
cases assemble it without having to add any kind of directive. With
masm, you would almost always have to ahve preprocessor directives in
there whether you are trying to produce an executable, a binary file
or an object file.
>I'm using TASM for RealMode (16:16), ALP for Protected Mode (32:0) and
>sometimes MASM, if I have to modify other commercial projects.
I'm using NASM for everything I do in assembly language at the moment,
and have never had a problem with it.
>
>> > PUSH byte would mean that one would want to "actually" push a byte to
>> > stack and that's impossible.
>> Well, I agree that actually pushing just a single byte is impossible (of
>> course),
>
>nice.
What does that mean? All Frank said was that the processor can't push
a byte, not that it can't recognise that a push instruction has a byte
operand. The instruction to push a byte sign extends it to the default
operand size, and the processor handles that correctly in 100% of
cases. It also saves space in the assembled program.
>
>0FFh is always considered as a unsigned variable. So why should it
>warn you about it. (that's why the "0" is required, you can't specify
>"FFh").
Wrong. 0FFh is treated as unsigned if it is used for an instruction
that operates on unsigned values, and as a signed value for
instructions that only operate on signed values.
>It's warning because of the byte directive and because it's impossible
>to push bytes.
You're thinking of some other assembler there. Nasm warns because it
expects a signed byte and doesn't know that the programmer has written
the value with the intention of it being signed.
>If he wants to specify every single opcode, then he should use
>inline-assembly and a hex-editor. Assemblers do (normally) what they
>are supposed to do.
An assembler does what it has been written to do. If it has been
written to support every instruction in the Intel, AMD and Cyrix
processor documents, then it will support them.
>
>If it's correct, then why does the warning come up ?
>And what has this do to do with the syntax ? The syntax is correct,
>but the logic isn't.
See above. The warning is because if the value was meant to be 255,
then it could ahve been an error (if popped as a word, it would be
65535). The assembler does not know that when it is popped the high
byte is going to be discarded. It emits an error, but that doesn't
mean that it will emit an error and stop assembling, only that it
warns you in case you have done something wrong. If you then want to
change it to look differently in the source code (and produce the same
machine code bytes) then you can, but you dont ahve to. As said by
Frank, that is something that may get sorted out, so you can suppress
such warnings, but as the code does assemble and the assembled code
works it is not a high priority for everyone working on nasm.
>> it's reasonable for Nasm to generate the warning, but I agree with Chris
>> that it should be suppressable (and maybe even "off" by default ???). In
>> spite of the warning, Nasm *is* generating 6A FF, as desired.
>
>Actually, NO, because PUSH BYTE [value] is NOT correct. Get it ?
Actually NO, because PUSH BYTE <value> IS correct. Get it? For
reference, see Pentium ® Processor Family Developer’s Manual, Volume
3: <ftp://download.intel.com/design/pentium/manuals/24143004.pdf>,
appendix F (the instruction format and encoding section), where it
says:
PUSH – Push Operand onto the Stack
immediate 0110 10s0 : immediate data
For the 's' bit, it says (on page F-4)
The s field occurs primarily in instructions with immediate data
fields. The s field has an effect only if the size of the
immediate data is 8 bits and is being placed in a 16-bit or
32-bit destination.
Encoding of Sign-Extend (s) Field
+------------------------------------------------------------+
| s Effect on | Effect on Immediate |
| Immediate Data8 | Data16 or Data32 |
+---------------------------------------------------------- +
| 0 None | None |
| 1 Sign-extend data8 to fill | |
| 16-bit or 32-bit destination | None |
------------------------------------------------------------+
In Section 25, page 25-253, it say (about the push instructions):
+------------------------------------------------------+
| Opcode | Instruction | Clocks | Description |
+------------------------------------------------------+
| 6A | PUSH imm8 | 1 | Push immediate byte |
| 68 | PUSH imm16 | 1 | Push immediate word |
| 68 | PUSH imm32 | 1 | Push immediate dword |
+------------------------------------------------------+
Of course, the Intel docs could be wrong (they have been wrong in the
past), but Intel Architecture Software Developer’s Manual Volume 2
<ftp://download.intel.com/design/pentium/manuals/24319101.PDF>
says the same (pages 3-385 and B-3/B-13), as does the Pentium 4
documentation (I'll let you look up the page numbers in there if you
still doubt the validity of the instruction).
>
>PUSH DWORD would be correct, because the command would push the value
>as DWORD to stack.
>PUSH WORD would be correct, because the command would push the value
>as WORD to the stack.
>but
>PUSH BYTE is INCORRECT, because it's not possible to push single bytes
>to stack. That's the problem.
See above, The processor seign extends the byte value. The byte form
of the instruction allows you to encode smaller integers with smaller
code size.
>
>Push BYTE is not considered as "how-the-opcode-is-done", but "what the
>value represents".
>
>that's why you have to specify:
>mov dx, word ptr [whateverpointer]
Depends on the assembler, different assemblers expect things to be
done slightly differently. That doesnt make any assembler right or
wrong, they just understand different syntax.
>
>You can do:
>PUSH WORD 77h -> for pushing the word 77h to the stack
>or
>PUSH DWORD 77h -> for doing a PUSHD (DWORD-Push) to stack
>
>seems logical ? That's why PUSH BYTE is invalid and the warning is
>absolutely correct. It's fixable, but it's invalid.
PUSH BYTE 77h would be right in any assembler that understands the
full x86 instruction set, and even nasm wouldn't generate a warning as
it is small enough that it couldn't possible represent a signed byte.
If MASM, TASM or ALP don't recognise it, it's because they do not ahve
the full instruction set supported (although, based on the fact that
one of my books does mention the instruction, I would guess that MASM
does support it - I haven't tested, but the book is older than nasm
and uses masm syntax throughout....).
>
>> Which assembler is it you think one should buy a book on, or "not use
>> assembly"? You *do* realize they're not all the same, right?
>
>I never found one book, where the stack was not explained. Simple as
>that.
There is a BIG difference between what you can push on the stack and
what you can tell the processor to put on the stack. The PROCESSor
PROCESSes the instructions and operands before doing its job, and in
the case of PUSH BYTE, the PROCESS includes sign extending the byte to
fill the 16 or 32 bit value (depending on the default operand size).
>One of the problems, why assembly is considered as so "bad", is
>because C programmers (or someone like that) "try" to do assembly,
>without knowing what they are doing. Learning how to code in assembly
>is not trivial and if you don't know how to do it, you should use
>high-level language instead.
If that's true, why are you so sure that you are right when the
processor docs obviously show that everyone else is right in this
case? Did you bother to look it up in the processor docs, or did you
assume that your favourite assembler book has got everything in it and
made no mistakes?
Ka-Chi CHEUNG
On Thu, 31 Jan 2002, Randall Hyde wrote:
>
> Martin Kiewitz wrote in message ...
> >On Thu, 31 Jan 2002 01:55:59 UTC, "Randall Hyde" <rh...@cs.ucr.edu>
> >wrote:
> >
> >> >[ ] You know that assemblers don't separate unsigned from signed
> >> >values. The programmer has to do it. (#1)
> >> >Argh, go back to writing C programs, PLEASE.
> >> >cu, Kiewitz
> >> >P.S.: #1 - That's why JA/JB and JG/JL opcodes exist.
> >> I truly believe you are confusing the x86 processors and
> >> how they operate with how assemblers operate.
> >> Many assemblers most assuredly differentiate signed and
> >> unsigned values. MASM does. TASM does. HLA does.
> >
> >MASM does not. TASM does not.
>
> Okay, you are ignorant of MASM 6.x and TASM 5.x.
> But your ignorance doesn't change the fact that these
> assemblers provide support for signed versus unsigned
> variables.
>
> >
> >Tell me how to specify an unsigned byte and a signed byte.
> >I'm really interrested in knowing it.
>
> MASM (and TASM):
>
> signedInt32 sdword ?
> signedInt16 sword ?
> signedInt8 sbyte ?
Just to put the nail in his coffin, here's the specification from
MASM which tells Mr Kiewitz that unsigned and signed numbers are different
dataType BYTE | SBYTE | WORD | SWORD | DWORD |SDWORD | FWORD
| QWORD | TBYTE | REAL4 | REAL8 | REAL10
Kiewitz Wrote:
> >So what to put there, so that the assembler will "automagically"
> >convert it to the correct one ? (JA/JB is unsigned and JL/JG is
> >signed, JE/JNE is equal/not equal, JC/JNC is for carry-flag. So where
> >is your "freakin" special opcode that gets transfered to the correct
> >one ?)
Actually, I would suspect that MASM 6.1's high level control
statement would use the information to generate the correct conditional
jump depending on whether the operands are signed or unsigned.
For someone who claims to know so much about assembly, yet don't
understand the underlying nature of modern assembler, I really wonder
whether it is you that should pack your bags and go back to the C boat?
Yours,
Ka-Chi
debs
On Tue, 29 Jan 2002 23:55:54 +0000 (UTC), Randall Hyde spake thus:
>Not that any of the other assemblers support this, but
>NASM proponents make such a big deal about the
>assembler doing "exactly what I tell it to" that this seems
>to be a problem that should be corrected.
>Randy Hyde
In this case, you ahve picked a bad example for why nasm should have a
way of pushing 255. To push it as 0x00FF you would ahve to push a
word, which is not what the original code asked for. To push it as
0xFF (ie -1) it will be coded as 0x6A 0xFF, but the processor will
convert that to the equivalent of 0x68 0xFFFF. Some code might
actually make use of the 0x6A 0xFF in some other place (as data,
possibly, or as part of a smc sequence that's used for soem other
purpose as well as the original purpose). In that case, changing it
behind the programmers back will have the opposite effect to what you
suggest......
debs
On Wed, 30 Jan 2002 20:55:57 +0000 (UTC), Martin Kiewitz spake thus:
>Perhaps he included some nice BITS 32 or BITS 16 directive.
>Nothing I can do about it.
>He should LEARN the basics of assembly and the usage of an assembler.
Perhaps you should learn what the processor is capable of.
>
>Nasm is not a good-assembler anyway. He should try ALP, TASM or MASM.
NASM is a great assembler. It's free, it's open source, it supports
all instructions up to the latest x86 instruction sets..... It's also
always assembled any valid x86 code that I've passed to it. I'm yet to
see a boot sector written in another assembler that can do everything
my boot sector can do plus more. If nasm is so bad, how come it can do
things as well as others (in fact, there are things you can't do in
masm that you can do in nasm, and which the Intel processor docs say
you can do). Nasm will also allow you to assemble code without having
to know all the assembler directives that you need for masm. With
nasm, you can take code directly out of the Intel manuals, and in most
cases assemble it without having to add any kind of directive. With
masm, you would almost always have to ahve preprocessor directives in
there whether you are trying to produce an executable, a binary file
or an object file.
>I'm using TASM for RealMode (16:16), ALP for Protected Mode (32:0) and
>sometimes MASM, if I have to modify other commercial projects.
I'm using NASM for everything I do in assembly language at the moment,
and have never had a problem with it.
>
>> > PUSH byte would mean that one would want to "actually" push a byte to
>> > stack and that's impossible.
>> Well, I agree that actually pushing just a single byte is impossible (of
>> course),
>
>nice.
What does that mean? All Frank said was that the processor can't push
a byte, not that it can't recognise that a push instruction has a byte
operand. The instruction to push a byte sign extends it to the default
operand size, and the processor handles that correctly in 100% of
cases. It also saves space in the assembled program.
>
>0FFh is always considered as a unsigned variable. So why should it
>warn you about it. (that's why the "0" is required, you can't specify
>"FFh").
Wrong. 0FFh is treated as unsigned if it is used for an instruction
that operates on unsigned values, and as a signed value for
instructions that only operate on signed values.
>It's warning because of the byte directive and because it's impossible
>to push bytes.
You're thinking of some other assembler there. Nasm warns because it
expects a signed byte and doesn't know that the programmer has written
the value with the intention of it being signed.
>If he wants to specify every single opcode, then he should use
>inline-assembly and a hex-editor. Assemblers do (normally) what they
>are supposed to do.
An assembler does what it has been written to do. If it has been
written to support every instruction in the Intel, AMD and Cyrix
processor documents, then it will support them.
>
>If it's correct, then why does the warning come up ?
>And what has this do to do with the syntax ? The syntax is correct,
>but the logic isn't.
See above. The warning is because if the value was meant to be 255,
then it could ahve been an error (if popped as a word, it would be
65535). The assembler does not know that when it is popped the high
byte is going to be discarded. It emits an error, but that doesn't
mean that it will emit an error and stop assembling, only that it
warns you in case you have done something wrong. If you then want to
change it to look differently in the source code (and produce the same
machine code bytes) then you can, but you dont ahve to. As said by
Frank, that is something that may get sorted out, so you can suppress
such warnings, but as the code does assemble and the assembled code
works it is not a high priority for everyone working on nasm.
>> it's reasonable for Nasm to generate the warning, but I agree with Chris
>> that it should be suppressable (and maybe even "off" by default ???). In
>> spite of the warning, Nasm *is* generating 6A FF, as desired.
>
>Actually, NO, because PUSH BYTE [value] is NOT correct. Get it ?
Actually NO, because PUSH BYTE <value> IS correct. Get it? For
<ftp://download.intel.com/design/pentium/manuals/24319101.PDF>
>PUSH DWORD would be correct, because the command would push the value
>as DWORD to stack.
>PUSH WORD would be correct, because the command would push the value
>as WORD to the stack.
>but
>PUSH BYTE is INCORRECT, because it's not possible to push single bytes
>to stack. That's the problem.
See above, The processor seign extends the byte value. The byte form
of the instruction allows you to encode smaller integers with smaller
code size.
>
>Push BYTE is not considered as "how-the-opcode-is-done", but "what the
>value represents".
>
>that's why you have to specify:
>mov dx, word ptr [whateverpointer]
Depends on the assembler, different assemblers expect things to be
done slightly differently. That doesnt make any assembler right or
wrong, they just understand different syntax.
>
>You can do:
>PUSH WORD 77h -> for pushing the word 77h to the stack
>or
>PUSH DWORD 77h -> for doing a PUSHD (DWORD-Push) to stack
>
>seems logical ? That's why PUSH BYTE is invalid and the warning is
>absolutely correct. It's fixable, but it's invalid.
PUSH BYTE 77h would be right in any assembler that understands the
full x86 instruction set, and even nasm wouldn't generate a warning as
it is small enough that it couldn't possible represent a signed byte.
If MASM, TASM or ALP don't recognise it, it's because they do not ahve
the full instruction set supported (although, based on the fact that
one of my books does mention the instruction, I would guess that MASM
does support it - I haven't tested, but the book is older than nasm
and uses masm syntax throughout....).
>
>> Which assembler is it you think one should buy a book on, or "not use
>> assembly"? You *do* realize they're not all the same, right?
>
>I never found one book, where the stack was not explained. Simple as
>that.
There is a BIG difference between what you can push on the stack and
what you can tell the processor to put on the stack. The PROCESSor
PROCESSes the instructions and operands before doing its job, and in
the case of PUSH BYTE, the PROCESS includes sign extending the byte to
fill the 16 or 32 bit value (depending on the default operand size).
>One of the problems, why assembly is considered as so "bad", is
>because C programmers (or someone like that) "try" to do assembly,
>without knowing what they are doing. Learning how to code in assembly
>is not trivial and if you don't know how to do it, you should use
>high-level language instead.
If that's true, why are you so sure that you are right when the
processor docs obviously show that everyone else is right in this
case? Did you bother to look it up in the processor docs, or did you
assume that your favourite assembler book has got everything in it and
made no mistakes?
debs
On Wed, 30 Jan 2002 17:56:05 +0000 (UTC), Martin Kiewitz spake thus:
>nice and friendly way you got.
>Actually you don't know what a stack is, otherwise you wouldn't use
>"push byte 0FFh".
>You know, stacks are built up of at least words.
The size and alignment of the stack is irrelevant. The PROCESSOR is
the thing that accepts the 'PUSH IMM8' instruction, and the PROCESSOR
adjusts the size of the operand to a size which is appropriate for the
current operand size. In the case of 32 bit code, it will be sign
extended to a 32-bit number, and for 16-bit code it would be sign
extended to a 16 bit value.
>
>for example: There is no PUSH AL, POP AL instruction. Interresting
>isn't it.
>Like I said, buy yourself an assembly book.
Read the Intel manuals if you think that what I am saying is wrong.
Everyone that you are disagreeing with is saying what the Intel
manuals say. The only difference between what others are saying is
that some don't mention (and therefore can't be assumed to either know
or not know) that it is a signed byte that the processor sees. However
many books you have read, there are a lot which don't mention that the
byte form is actually a signed byte form. As I ahve stated mroe than
once, even the Intel docs are not clear. Unless, of course, you think
everyone should read every word of all the relevant processor docs
before writing code for them, including knowing how the opcodes are
encoded (in which case nobody would need an assembler anyway - don't
you think it would be far easier if we all just wrote the code
directly in machine code? :)
>
>> C:\>nasm -f bin foo.asm
>> foo.asm:2: operation size not specified
>> It works under TASM, but produces the long form of the PUSH
>> instruction (4-byte operand):
>
>If you tell the assembler to use 32 bits, don't ask yourself why it
>actually does what you wanted.
The problem that Chris has is that he wants to generate the 8-bit form
of the push instruction. He has not said at any point (in the posts I
read) that he wants the provcessor to treat it as an 8-bit number,
only that he wants to use the 8-bit form of the instruction.
>Please go buy an assembly book or use another language. Assembly is
>not for wannabes.
Really?
Did you not wannabe* an assembly language programmer before you
learned whatever you have learned, or were you born knowing it?
* Don't forget, wannabe is a shortened form of 'want to be'. You have
to want to learn something before you can learn it, and if you never
ask questions you never find out if things are even possible, let
alone how to do them.
debs
On Wed, 30 Jan 2002 17:56:05 +0000 (UTC), Martin Kiewitz spake thus:
>nice and friendly way you got.
>Actually you don't know what a stack is, otherwise you wouldn't use
>"push byte 0FFh".
>You know, stacks are built up of at least words.
The size and alignment of the stack is irrelevant. The PROCESSOR is
the thing that accepts the 'PUSH IMM8' instruction, and the PROCESSOR
adjusts the size of the operand to a size which is appropriate for the
current operand size. In the case of 32 bit code, it will be sign
extended to a 32-bit number, and for 16-bit code it would be sign
extended to a 16 bit value.
>
>for example: There is no PUSH AL, POP AL instruction. Interresting
>isn't it.
>Like I said, buy yourself an assembly book.
Read the Intel manuals if you think that what I am saying is wrong.
Everyone that you are disagreeing with is saying what the Intel
manuals say. The only difference between what others are saying is
that some don't mention (and therefore can't be assumed to either know
or not know) that it is a signed byte that the processor sees. However
many books you have read, there are a lot which don't mention that the
byte form is actually a signed byte form. As I ahve stated mroe than
once, even the Intel docs are not clear. Unless, of course, you think
everyone should read every word of all the relevant processor docs
before writing code for them, including knowing how the opcodes are
encoded (in which case nobody would need an assembler anyway - don't
you think it would be far easier if we all just wrote the code
directly in machine code? :)
>
>> C:\>nasm -f bin foo.asm
>> foo.asm:2: operation size not specified
>> It works under TASM, but produces the long form of the PUSH
>> instruction (4-byte operand):
>
>If you tell the assembler to use 32 bits, don't ask yourself why it
>actually does what you wanted.
The problem that Chris has is that he wants to generate the 8-bit form
of the push instruction. He has not said at any point (in the posts I
read) that he wants the provcessor to treat it as an 8-bit number,
only that he wants to use the 8-bit form of the instruction.
>Please go buy an assembly book or use another language. Assembly is
>not for wannabes.
Really?
debs
On Wed, 30 Jan 2002 20:55:57 +0000 (UTC), Martin Kiewitz spake thus:
>Perhaps he included some nice BITS 32 or BITS 16 directive.
>Nothing I can do about it.
>He should LEARN the basics of assembly and the usage of an assembler.
Perhaps you should learn what the processor is capable of.
>
>Nasm is not a good-assembler anyway. He should try ALP, TASM or MASM.
NASM is a great assembler. It's free, it's open source, it supports
all instructions up to the latest x86 instruction sets..... It's also
always assembled any valid x86 code that I've passed to it. I'm yet to
see a boot sector written in another assembler that can do everything
my boot sector can do plus more. If nasm is so bad, how come it can do
things as well as others (in fact, there are things you can't do in
masm that you can do in nasm, and which the Intel processor docs say
you can do). Nasm will also allow you to assemble code without having
to know all the assembler directives that you need for masm. With
nasm, you can take code directly out of the Intel manuals, and in most
cases assemble it without having to add any kind of directive. With
masm, you would almost always have to ahve preprocessor directives in
there whether you are trying to produce an executable, a binary file
or an object file.
>I'm using TASM for RealMode (16:16), ALP for Protected Mode (32:0) and
>sometimes MASM, if I have to modify other commercial projects.
I'm using NASM for everything I do in assembly language at the moment,
and have never had a problem with it.
>
>> > PUSH byte would mean that one would want to "actually" push a byte to
>> > stack and that's impossible.
>> Well, I agree that actually pushing just a single byte is impossible (of
>> course),
>
>nice.
What does that mean? All Frank said was that the processor can't push
a byte, not that it can't recognise that a push instruction has a byte
operand. The instruction to push a byte sign extends it to the default
operand size, and the processor handles that correctly in 100% of
cases. It also saves space in the assembled program.
>
>0FFh is always considered as a unsigned variable. So why should it
>warn you about it. (that's why the "0" is required, you can't specify
>"FFh").
Wrong. 0FFh is treated as unsigned if it is used for an instruction
that operates on unsigned values, and as a signed value for
instructions that only operate on signed values.
>It's warning because of the byte directive and because it's impossible
>to push bytes.
You're thinking of some other assembler there. Nasm warns because it
expects a signed byte and doesn't know that the programmer has written
the value with the intention of it being signed.
>If he wants to specify every single opcode, then he should use
>inline-assembly and a hex-editor. Assemblers do (normally) what they
>are supposed to do.
An assembler does what it has been written to do. If it has been
written to support every instruction in the Intel, AMD and Cyrix
processor documents, then it will support them.
>
>If it's correct, then why does the warning come up ?
>And what has this do to do with the syntax ? The syntax is correct,
>but the logic isn't.
See above. The warning is because if the value was meant to be 255,
then it could ahve been an error (if popped as a word, it would be
65535). The assembler does not know that when it is popped the high
byte is going to be discarded. It emits an error, but that doesn't
mean that it will emit an error and stop assembling, only that it
warns you in case you have done something wrong. If you then want to
change it to look differently in the source code (and produce the same
machine code bytes) then you can, but you dont ahve to. As said by
Frank, that is something that may get sorted out, so you can suppress
such warnings, but as the code does assemble and the assembled code
works it is not a high priority for everyone working on nasm.
>> it's reasonable for Nasm to generate the warning, but I agree with Chris
>> that it should be suppressable (and maybe even "off" by default ???). In
>> spite of the warning, Nasm *is* generating 6A FF, as desired.
>
>Actually, NO, because PUSH BYTE [value] is NOT correct. Get it ?
Actually NO, because PUSH BYTE <value> IS correct. Get it? For
<ftp://download.intel.com/design/pentium/manuals/24319101.PDF>
>PUSH DWORD would be correct, because the command would push the value
>as DWORD to stack.
>PUSH WORD would be correct, because the command would push the value
>as WORD to the stack.
>but
>PUSH BYTE is INCORRECT, because it's not possible to push single bytes
>to stack. That's the problem.
See above, The processor seign extends the byte value. The byte form
of the instruction allows you to encode smaller integers with smaller
code size.
>
>Push BYTE is not considered as "how-the-opcode-is-done", but "what the
>value represents".
>
>that's why you have to specify:
>mov dx, word ptr [whateverpointer]
Depends on the assembler, different assemblers expect things to be
done slightly differently. That doesnt make any assembler right or
wrong, they just understand different syntax.
>
>You can do:
>PUSH WORD 77h -> for pushing the word 77h to the stack
>or
>PUSH DWORD 77h -> for doing a PUSHD (DWORD-Push) to stack
>
>seems logical ? That's why PUSH BYTE is invalid and the warning is
>absolutely correct. It's fixable, but it's invalid.
PUSH BYTE 77h would be right in any assembler that understands the
full x86 instruction set, and even nasm wouldn't generate a warning as
it is small enough that it couldn't possible represent a signed byte.
If MASM, TASM or ALP don't recognise it, it's because they do not ahve
the full instruction set supported (although, based on the fact that
one of my books does mention the instruction, I would guess that MASM
does support it - I haven't tested, but the book is older than nasm
and uses masm syntax throughout....).
>
>> Which assembler is it you think one should buy a book on, or "not use
>> assembly"? You *do* realize they're not all the same, right?
>
>I never found one book, where the stack was not explained. Simple as
>that.
There is a BIG difference between what you can push on the stack and
what you can tell the processor to put on the stack. The PROCESSor
PROCESSes the instructions and operands before doing its job, and in
the case of PUSH BYTE, the PROCESS includes sign extending the byte to
fill the 16 or 32 bit value (depending on the default operand size).
>One of the problems, why assembly is considered as so "bad", is
>because C programmers (or someone like that) "try" to do assembly,
>without knowing what they are doing. Learning how to code in assembly
>is not trivial and if you don't know how to do it, you should use
>high-level language instead.
If that's true, why are you so sure that you are right when the
processor docs obviously show that everyone else is right in this
case? Did you bother to look it up in the processor docs, or did you
assume that your favourite assembler book has got everything in it and
made no mistakes?
Beth
> Martin still insists on carrying on with this by writing:
> > Push BYTE is not considered as "how-the-opcode-is-done", but "what the
> > value represents".
>
> What?
His book doesn't give the terminology for type casting, I think...this is
Martin's attempt to explain it...or, at least, I hope it is or he's making
less sense than I'm giving him credit for...
> > I never found one book, where the stack was not explained. Simple as
> > that.
> > One of the problems, why assembly is considered as so "bad", is
> > because C programmers (or someone like that) "try" to do assembly,
> > without knowing what they are doing. Learning how to code in assembly
> > is not trivial and if you don't know how to do it, you should use
> > high-level language instead.
>
> It appears that your book may have explained the stack and it's
> instructions inadequately. You seem not to understand what it is that
> we're talking about here. I agree that asm is not trivial, but I don't
> think it's "bad" just because someone's opinion of their understanding
> exceeds their understanding.
Because, if this were "bad", Martin would be the most guilty of being "bad"
around here, nicht wahr?
Beth:)
Beth
> For someone who claims to know so much about assembly, yet don't
> understand the underlying nature of modern assembler, I really wonder
> whether it is you that should pack your bags and go back to the C boat?
Or, more productively, we stop with this jumping to conclusions about people
stuff and listen to what's said and then we can all stick with ASM and
nobody has to catch the C boat...or, in other words, rather than the usual
crap of running around trying to prove yourself the best ASM programmer in
the universe and that everyone else is wrong, how about looking at it from
the perspective that everyone here knows at least something about ASM and
that we can't know everything and, just possibly, someone might have
something to point out that we didn't notice or understand before...or, in
short, it is the wise who listen and those who don't, tend to just want to
be perceived as wise rather than actually being the "real thing"(tm)...
Beth:)
Beth
> Martin Kiewitz spouted:
> > Frankie say:
> > > > First, PLEASE buy yourself an assembly book and learn what the stack
> > > > is or don't use assembly.
> > > > The answer: use "Push 0FFh", without byte.
> > > That'll generate 68 FF 00 - Chris was clear that he wanted 6A FF -
which
> >
> > no.
>
> No, what? No that's not what Chris wanted, or no that's not what Nasm's
> giving him? I can't be sure what Chris wanted (tho that's what he said),
> but I assure you that that *is* what Nasm will do. (okay, that's 16-bit
> code - Chris said 32-bit, so 68 FF 00 00 00 ...)
He means "no! my ego will not except I got it wrong", I think...hehehe :)
You're absolutely right, Frank...Chris made himself quite clear about what
he was looking for (a means to surpress an annoying NASM warning) and quite
why Martin's insistant on inventing problems that aren't there is beyond
good reason...
> > > he's getting (right?), but with an undesired warning (not
suppressable,
> > > maybe it should be) from Nasm.
> >
> > actually no. Any assembler will automatically use the best opcode for
> > that job.
Sorry, we're talking NASM, Martin...NASM has a certain unique philosophy
amongst assemblers and you can't say that about it...NASM's philosophy is to
generate the opcode it's asked to generate and leaves optimisation fully in
the programmers' hands...
But, of course, you've bothered to read the NASM manuals and have "got
informed" about this sort of thing before you would even consider commenting
on such "critical work", right? So, of course, you already knew this, didn't
you? Because you obviously wouldn't be so dense as to go around preaching to
everyone else about what they should do and not take your own advice, right?
> If by "any assembler", you mean "all assemblers", I have to disagree
> again. If you mean "some assembler" will do this, okay, which one did
> you have in mind?
Whichever one serves to boost his insatiable ego, it appears...
> > PUSH byte would mean that one would want to "actually" push a byte to
> > stack and that's impossible.
No, not at all..."push byte" is something you'll find in most assemblers (in
one form or another) but in NONE OF THEM does it mean "please push a byte
onto the stack"...I mean, as you're so fond of pointing, it can't mean that,
as it's impossible on an x86...but maybe you should go read that assembly
book of yours, Martin, as you'll find it doesn't mean what you think it does
and _is_ permissible...
> Well, I agree that actually pushing just a single byte is impossible (of
> course), but what "push byte" means depends on the assembler. In Nasm
> syntax, it will do exactly what (I think) Chris wants - 6A FF. It's just
> that if you express the operand as "0FFh" rather than "-1", Nasm warns
> you...
Which actually begs the question of whether it should actually be Martin who
returns to using C because that should give him enough practice to recognise
a type cast when he sees one...in fact, may I suggest to you, Martin, that
in addition to your precious assembly book, you might consider purchasing a
book about programming in general...one that explains simple notions like
type casting, pointers, stacks and such...although, actually, maybe you
could save your pennies and go to Randy's website and download his "Art of
Assembly" electronic book (you know Randy, right? Yeah, he's the one you
earlier reprimanded for not knowing how assemblers work...yeah, you know,
the one who's written his own comprehensive assembler that works intimately
with MASM and TASM (and is working on NASM compatibility) and has produced a
massive amount of documentation, verified by hundreds if not thousands, of
ASM coders that swear by it and is constantly recommended by almost everyone
here...i.e. the person you told to go back to using C is an ASM guru of many
years and one of its strongest proponents...perhaps more years than some
have been alive...you advised "getting informed" before passing comment, so
take your own advice, please ;)...
> > > Grzegorz had the right answer, I think - use "-1" or whatever. Or just
> > > ignore the damn warning :)
> >
> > If you think so. Using "Push byte" is just fault, but "recoverable",
> > that's why the warning comes up.
His arrogance knows no bounds, it appears...not content with telling Randy
how assemblers work, he's now decided to reprimand Frank for not knowing
about NASM syntax...of course, those of us who actually know what's what
around here will know the immense folly of both actions but Martin's
starting to nnoy me, so I'll not explain to him why he's being so stupid
here and just enjoy sitting back and watching him make a fool of himself...
No doubt, if Linus was here, he'd tell him he doesn't understand OSes...or
Abrash that he doesn't know how to optimise properly...
> I *do* think so, yes! It may be that "push byte" is a "fault" in some
> assemblers' syntax, but it's correct for Nasm. I personally feel that
> it's reasonable for Nasm to generate the warning, but I agree with Chris
> that it should be suppressable (and maybe even "off" by default ???). In
> spite of the warning, Nasm *is* generating 6A FF, as desired.
>
> Which assembler is it you think one should buy a book on, or "not use
> assembly"? You *do* realize they're not all the same, right?
No doubt, his experience with C - which is standardised - is confusing
him...perhaps he should return to it for a refresher course...hehehe :)
No, only kidding...telling someone not to use ASM because they have a single
minor annoyance with a warning message has got to be about the stupidest
advice I've heard...no offence, Martin, but it honestly is...rather than
tell anyone who has problems never to use ASM, I'd advise you learn more
about it..."get yourself informed"...feel free to ask questions here, of
course...though we're all complete morons who haven't read any books, we
perhaps can work together to offer something of value to you...
Don't worry, I promise that if you drop the ego, I'll drop the sarcastic
comments...I don't bear grudges (or, with my scatty memory, even remember I
even said such things ;) to people who are honestly wanting some
help...let's start again fresh, yes? I'm sure we can all get on once you
drop the ego :)...
Beth:)
Beth
For the UK people who were around in the 80s and like music, you might
appreciate this little joke:
Frankie say: "No more!!"
Beth ;)
[ P.S. to explain, there was a band in the 80s in the UK called "Frankie
Goes To Hollywood" and they used iconography and were very
image-based...anyway, there was loads of merchandise to go with the band
(including, for those who've got a C64 or Spectrum emulator for their PC and
want to check it out, a computer game based on the band...and, despite the
insanity of the idea of making a computer game about a band, it's actually
one of the most radical and well-designed games ever made to date...download
it and see what I mean...it's entirely mad but it's way cool...plus, in one
of the many subgames, you get the pleasure of shooting Maggie and Reagan,
which is worth the download in itself...hehehe ;)...and they had these
T-shirts that read "Frankie say" this and "Frankie say" that...also, the
"Pleasuredome" album (for those without qualms of breaking copyright laws,
it should be possible to find it on some Napster-alike...although, I don't
condone such things and actually, myself, own the album on CD :) ends with a
big climax in the song "Bang!!", which ends with the "Frankie say: No more"
quote above...as I always for an in-joke put "Frankie say" on Frank's posts,
I couldn't resist the temptation for making this joke...I apologise that
it's "regional" and probably most of you wouldn't get it :)... ]
Beth
> Chris Giese wrote:
> > >First, PLEASE buy yourself an assembly book and learn what the stack
> > >is or don't use assembly.
> > I know how to use asm and I know what a stack is, you patronizing
> > asshole.
>
> nice and friendly way you got.
Looking at the stream of foul language and unwarranted insults you gave
Frank, you are the last to talk...though Chris should probably have tempered
his langauge, in comparison to your effing and blinding in response to
Frank, Chris is positively angelic for his mild swearing...
> Actually you don't know what a stack is, otherwise you wouldn't use
> "push byte 0FFh".
> You know, stacks are built up of at least words.
>
> for example: There is no PUSH AL, POP AL instruction. Interresting
> isn't it.
> Like I said, buy yourself an assembly book.
Although, as you seem to go on and on about your precious assembly book,
then maybe the advice here should be "actually read the book you've
bought"...I cannot honestly believe that even the crappest assembly book
wouldn't, for example, explain about needing a "0" to differentiate between
an identifier and a constant...your comments regarding that make me believe
you either have the crappest assembly book in existence or that you've not
actually bothered to read it properly...and, certainly, you didn't bother to
refer to it before spouting your mouth off and assuming everyone to be
complete morons...
> > C:\>nasm -f bin foo.asm
> > foo.asm:2: operation size not specified
> > It works under TASM, but produces the long form of the PUSH
> > instruction (4-byte operand):
>
> If you tell the assembler to use 32 bits, don't ask yourself why it
> actually does what you wanted.
> Please go buy an assembly book or use another language. Assembly is
> not for wannabes.
Why? You've bought an assembly book and it hasn't stopped you being totally
wrong...
Beth:)
Beth
> 0FFh is always considered as a unsigned variable. So why should it
> warn you about it. (that's why the "0" is required, you can't specify
> "FFh").
Incorrect; the "0" before hexadecimal constants is simply used to enable the
assembler to differentiate between a hex constant and an identifer that
coincidentally starts with a hex digit...that is, "FFh" is actually a valid
name to give to an identifier, so you need to put in the "0" and make "0FFh"
which, starting with a digit, makes clear it's a hexadecimal constant...the
addition of the "0" will NOT effect the size it interprets for the
constant...if you don't believe me, please feel free to read your assembly
books on the matter...as all assemblers that use the Intel suffix syntax are
similar, it should be explained in the book where it explains about what is
a valid identifier and what isn't...I mean, you've bought the book, right?
Surely it would be a waste of money unless you actually read it :)..
> It's warning because of the byte directive and because it's impossible
> to push bytes.
Incorrect; The warning has nothing to do with the "impossibility of pushing
bytes" (which is actually not correct...it is impossible for a byte value to
be put directly onto the stack but it is possible to push a byte value,
which the CPU implicitly sign extends, onto the stack..."pushing bytes" is
possible...having bytes put onto the stack by the CPU is what's
impossible...there is a subtle difference :)...the warning refers to NASM
assuming that an immediate constant in a push statement is signed and, thus,
the unsigned value it's assuming to be a potential mistake...it
isn't...NASM, a bit like you tend to do, is actually drawing conclusions it
shouldn't be...
> If he wants to specify every single opcode, then he should use
> inline-assembly and a hex-editor. Assemblers do (normally) what they
> are supposed to do.
"Inline machine code", actually...inline assembly within assembly is a
bizarre concept...and a hex editor seems a touch extreme for this
situation...
And, actually, the irony is that the real problem here (as opposed to the
problems you're inventing) is that NASM is actually not really doing what
its told (which is against its philosophy...maybe this is something to
review in the NASM developers forum :)...
> > > > Grzegorz had the right answer, I think - use "-1" or whatever. Or
just
> > > > ignore the damn warning :)
> > > If you think so. Using "Push byte" is just fault, but "recoverable",
> > > that's why the warning comes up.
> > I *do* think so, yes! It may be that "push byte" is a "fault" in some
> > assemblers' syntax, but it's correct for Nasm. I personally feel that
>
> If it's correct, then why does the warning come up ?
A warning is not an error, nor does it mean that the code is actually
wrong...a warning is a message generated by the assembler to, as you might
expect, warn the programmer that there could be a potential problem in the
code...it's not an error because nothing is actually wrong and there are
occasions where such code is entirely correct...the warnings, though, pick
up on common mistakes and point them out, so that if something is wrong, it
can be detected and corrected...again, your assembly book should mention
something about the differences between warnings and errors (if not, buy a
better book that does :)...
> And what has this do to do with the syntax ? The syntax is correct,
> but the logic isn't.
Close; The logic is correct (Chris does want this to happen and it is
possible:) and the syntax is also correct (in a sense)...what the problem
is, is that the assembler is issuing a warning about something that isn't
actually wrong...what we want to know is how to let the assembler know that
it's correct...there are two options here to find a way to shut NASM up so
it doesn't generate a warning...either there's some sort of switch/directive
to give the assembler to tell it not to consider the code worthy of a
warning or we can alter the syntax of the instruction to make it explicit to
NASM that we know what we're doing (and putting "-1" does that...although,
this _is_ a syntax issue because it means entering a signed constant to tell
NASM to shut up, when it's logically an unsigned value :)...
> > it's reasonable for Nasm to generate the warning, but I agree with Chris
> > that it should be suppressable (and maybe even "off" by default ???). In
> > spite of the warning, Nasm *is* generating 6A FF, as desired.
>
> Actually, NO, because PUSH BYTE [value] is NOT correct. Get it ?
Well, well...someone's not paying attention...we're pushing an immediate
here...thus, "push byte value" not "push byte [value]", which is not the
same thing at all (but then, if you'd read Chris' original post, you'd see
he specified 6Ah as the opcode and could have checked that up in your
assembly books or any Intel reference to see that it's "push immediate
8-bit" and not "push 8-bit memory" :)...
> PUSH DWORD would be correct, because the command would push the value
> as DWORD to stack.
> PUSH WORD would be correct, because the command would push the value
> as WORD to the stack.
Yes; but not for the reasons you think...these, using a touch of C syntax to
make it clear, something more like "push ((dword) 0FFh)" or "push ((word)
0FFh)"...the "dword" and "word" are not part of the instruction but are type
casts on the constant to make sure it's of the correct size, which is then
passed to the push instruction and the correct opcode generated...if you
don't understand what I mean by type casting, look it up in some books :)...
> but
> PUSH BYTE is INCORRECT, because it's not possible to push single bytes
> to stack. That's the problem.
Incorrect; The "push byte" stuff in pseudo-ASM/C mix is "push ((byte)0FFh)",
which ensures that the immediate operand is interpreted as an 8-bit
value...then there is an opcode (6Ah) which encodes "push imm8" and this is
the instruction we want in our code...only when this instruction is executed
will the byte value be sign extend and a word/dword value pushed onto the
stack...
> Push BYTE is not considered as "how-the-opcode-is-done", but "what the
> value represents".
Oh...so, though you can't express it properly, you do have an understanding
of what type casting is...which then begs the question why you can't see
that "push byte" is ok (please, please, go look up opcode 6Ah and read up on
it before continuing to post...thanks :)...
> that's why you have to specify:
> mov dx, word ptr [whateverpointer]
Yes...
> You can do:
> PUSH WORD 77h -> for pushing the word 77h to the stack
> or
> PUSH DWORD 77h -> for doing a PUSHD (DWORD-Push) to stack
>
> seems logical ? That's why PUSH BYTE is invalid and the warning is
> absolutely correct. It's fixable, but it's invalid.
Aaah...so what you mean is that the CPU, at execution time, will perform
something like: "push (word)((byte)0FFh)"? That's true but that's _during
execution_...it is valid to have "push ((byte)0FFh)" as an assembly
instruction...you're confusing "what-gets-done" for "what-we-write"...there
is a difference...
> > Which assembler is it you think one should buy a book on, or "not use
> > assembly"? You *do* realize they're not all the same, right?
>
> I never found one book, where the stack was not explained. Simple as
> that.
> One of the problems, why assembly is considered as so "bad", is
> because C programmers (or someone like that) "try" to do assembly,
> without knowing what they are doing. Learning how to code in assembly
> is not trivial and if you don't know how to do it, you should use
> high-level language instead.
So, pray tell, how does anyone ever learn how to use ASM? You are
invalidating anyone from ever attempting anything, as it might be possible
for them to make a mistake...which is a problem as the best teacher tends to
be hands on experience and a bit of trial and error...although, putting this
with your other comments about buying assembly books, it would seem that
you're suggesting that no-one should ever attempt to write any ASM code
whatsoever until they've learnt every single facet of everything there
possibly is to know...an interesting philosophy...luckily for you, no-one
does this or you'd find you couldn't get a doctor when you're ill (because
no doctor knows every single thing that's possible to know about human
biology..they know sufficient to proceed and learn more as they practice)...
Actually, a greater blight on assembly is that it tends to attract egotists
who want to prove they're the best thing since sliced bread and who tend to
refuse to listen to anyone else...the "hacker wannabies"...this ruins ASM as
an attractive prospect and has brought disrepute to the practice...as for
people not knowing what they're doing, this is a minor thing...they will
try, fail and learn...it's called trial and error...
But, of course, after telling Randy and Frank that they don't know what
they're talking about, in fields they very much do understand...you'll no
doubt try to tell me I don't understand the learning process, despite having
lots of AI experience to tell you that trial and error _is_
learning...success teaches you nothing...the fear of failure prohibiting you
learning is a far greater problem than a simple mistake...mistakes are ten a
penny...everyone does them and they are a touch unavoidable...ASM isn't
"bad", it's attitudes like this that are "bad"...if you want to live
yourself that safely, so that you avoid any potential to make any mistakes
ever, you'll never learn anything and you'll never achieve anything...
Of course, you'll no doubt tell me that I'm wrong...I expect nothing
less...and it's good to see that despite your claims, you are actually
willing to risk being wrong in order to progress...
Beth:)
Beth
> If you specify BYTE in front of, the assembler thinks you want to push
> a BYTE and that's actually impossible.
> The PUSH BYTE opcode just uses 8-bit for actually pushing a 16-bit
> value to stack. It's just saving one byte, when not needed, but it's
> not pushing a byte, it's pushing a word.
If this is an entry in the Hugi Size compo (or similar application where
code size matters), then that byte saved in the instruction stream might be
useful...even if it'll actually push a word to the stack...I think the OP
wasn't that insistent on actually pushing a physical byte to the stack but,
rather, on having the short encoding (I quote, "I want NASM to generate the
short PUSH instruction (opcode 6Ah)." :)...
I would venture that you're just assuming that Chris is stupid (for no good
reason, other than you seem to insist on exerting some sort of unwarranted
authority over everyone here) and that he actually believed that it would
push a byte to the stack...the fact that Chris states the opcode itself and
asks for "the short PUSH instruction" would tend to suggest to me that he's
either aware already of this stuff (or doesn't care about what goes on the
stack:)...
Note that there isn't actually any "problem" here but Chris wanting to know
how to shut up NASM's warning (but, if you insist, we can invent problems
for you to "solve", as you seem to need a lot of ego massage :)...it does,
from what he says, generate the code sequence he's looking for...your
discussion here might be right but it's completely irrelevent...the question
here is "how do we shut NASM up?"...that's all...and quite why you keep
wanting to jump to conclusions about other people's knowledge (Chris you
assume doesn't know what he wants and Randy that he doesn't know what he's
talking about...and, in both cases, the evidence suggests contrary to your
assumptions) is quite enigmatic, I have to say...
> > If the OP wanted to push 255, then it would have to be pushed as a
>
> It will use a WORD for it, that's why the assembler gets confused by
> the PUSH BYTE XXX instruction.
> That's why I said that one should buy an assembly book before using
> assembly.
Good advice; May also advise, then, that you purchase the correct book and
actually bother to refer to it...what you said about MASM and TASM not
recognising signed and unsigned declarations was simply wrong...they
do...and, in NASM's case, it does permit the 6Ah opcode encoding Chris wants
to use...the problem, as Frank has pointed out, is in telling NASM to shut
up because Chris does know what he wants...and, as Frank points out too,
this is actually a case of NASM being idosyncratic and straying from its own
philosophies about assuming that the programmer knows what they're doing...
And, in that spirit, perhaps you should also take a leaf out of NASM's book
and similarly assume that Chris knows what he wants and what he's doing (as
his OP suggests strongly :)...oh, and while you're at it, that Randy, who
developed both HLA and did so on top of MASM (with TASM compatibility) has
read and does know how those particular assemblers interpret things (it
would be difficult to have HLA produce the correct code otherwise, wouldn't
it?:)...
The assembler, actually, is not confused at all by the "push byte", it is
comprehending it and generating the required opcode sequence as
expected...what it's not doing, though, is assuming that the programer knows
what s/he's doing (which is actually against usual NASM philosophy :) and
not generating a bunch of warnings about it...all that we want to know here
is how to shut NASM up...that's all...nothing else is involved...there are
no additional problems, however much you'd like to invent some...
The machine will, as you say, sign extend and push a word rather than a
byte...but, to be honest, we just don't care...the exercise of using the
shorter encoding is, obviously, to reduce the code size...the run-time size
of operands on the stack is interesting but irrelevent to the requirements
we've got...and, anyway, the fact that you can't pop the data back into an
8-bit register with the available instruction set would serve as a big, big
hint about the nature of the stack to anyone paying attention and, dare I
say, reading the manuals and their assembly books...
> > - so I think it's a fair mistake for anyone to make the first time
> > they come across it.
>
> You find that everywhere. Just get yourself informed, before trying to
> do such critical work. If you don't want to, simply use C or some
> other language, but please not assembly.
To this there is only one suitable response:
"Fudge off, you arrogant little sh*t" [ edited for family viewing but I'm
sure you can work out what I was actually saying :) ]
No-one had actually made any mistake (except, possibly, NASM, depending on
whether you agree with NASM philosophy :)...and, even if they had, what sort
of advice is "if you make any mistakes ever with ASM, you should cease using
it and use C instead"? If that's the case, then no-one would be using
ASM...and, if extended, do we also suggest that if someone makes a mistake
in C that they should cease using that and use VisualBASIC instead? Where
does this ludicrous pile of crap advice end?
And, top of the list, your advice is utterly contradictory,
anyway...wouldn't Chris (or anyone else) posting their questions here
actually qualify as "getting yourself informed"? He came here to ask a
legitimate question (which, contrary to your assumptions, showed he was
fully aware of the underlying opcode encodings - he mentioned 6Ah
explicitly - and, thus, isn't as uniformed as your ego would like him to be)
and expected to "get informed" by other posters who might be able to
help...it just doesn't make any sense because you say "get yourself
informed" but when someone actually tries, you tell them that they are
inferior and should not use ASM ever again (which is hardly going to help
with them getting themselves informed now, is it? :)...
Add to that, I wouldn't call trying to get a specific opcode encoding as
"critical work"...your ego may have betrayed you and your actual experience
there...trying to get a certain machine encoding with ASM I would venture is
something the vast majority of us here would consider run of the mill work,
rather than what you suggest it is, as difficult, awkward and "critical
work"...if you honestly think this is immensely difficult and complex stuff,
then perhaps you should return to your precious assembly book and revise it
some more until you understand things better...
Look, maybe you can push this egotistical crap on "lesser mortals", who,
lacking any skills in this field, bow to your greatness in ASM...but here,
this isn't the case, we are your peers (if not a damn sight better than you
and, in the case of one or two, having ASM experience that goes back before
some of the posters here were even born)...we simply aren't impressed by a
few posts quoting incorrect facts, followed by a deep discussion about
something irrelevent and of no use to the OP, which, indeed, may show you
have some knowledge about something comparatively minor but also shows you
have a massive ego, social interaction issues and some deep insecurity that
you feel the need to assert your ego on us poor "mortals" every chance you
get...
In short, just grow up, will you?
> Stack on x86 is WORD-based. You will never find any stack that is able
> to push bytes.
And, pray tell, who asserted otherwise? Yup, that's right...no-one
did...rather, you invented an argument nobody made in order to show how
fantastic you are in correcting it...is your ego really that fragile it
needs this sort of boost?
Beth:)