Thomasz,
how Fasm encodes SMSW regarding 16/32 bit operands?
how Fasm encodes SMSW regarding 16/32 bit operands?
This instruction always uses 16-bit operands really, and there's only one encoding for it.
How would you explain then that
66 0F 01 E0
0F 01 E0
give you different results affecting eax?
Also Intel specifies that there can be 16 and 32 bit
operand use, though it says that "upper bits of 32 bit operand undefined" they are changed if prefix 66 is not specified.
On Heap section there are test results.
I really want to know your opinion, 'cause you're one
of most experienced guys on the opcode field here.
66 0F 01 E0
0F 01 E0
give you different results affecting eax?
Also Intel specifies that there can be 16 and 32 bit
operand use, though it says that "upper bits of 32 bit operand undefined" they are changed if prefix 66 is not specified.
On Heap section there are test results.
I really want to know your opinion, 'cause you're one
of most experienced guys on the opcode field here.
It's all very strange. The part of fasm that is responsible for smsw encoding has remained almost unchanged from 1999, when I was writing the first fasm version. I was using the Intel 80386 manual from 1986 that time, so I have looked into it once again now. It says:
Opcode Instruction Clocks Description
0F 01 /4 SMSW r/m16 2/3,pm=2/2 Store machine status word to EA
word
Operation
r/m16 MSW;
Description
SMSW stores the machine status word (part of CR0) in the two-byte register
or memory location indicated by the effective address operand.
Now we can look into the latest IA-32 architecture docs and what do we see? Two instructions: "SMSW r/m16" and "SMSW r32/m16". And you have shown that they really differ in behaviour. Maybe Intel had made such "bug" to simplify some things in the internal CPU architecture and then just documented it... Well, I see I'll have to change that part of fasm that lived unchanged so long time... ;)
Opcode Instruction Clocks Description
0F 01 /4 SMSW r/m16 2/3,pm=2/2 Store machine status word to EA
word
Operation
r/m16 MSW;
Description
SMSW stores the machine status word (part of CR0) in the two-byte register
or memory location indicated by the effective address operand.
Now we can look into the latest IA-32 architecture docs and what do we see? Two instructions: "SMSW r/m16" and "SMSW r32/m16". And you have shown that they really differ in behaviour. Maybe Intel had made such "bug" to simplify some things in the internal CPU architecture and then just documented it... Well, I see I'll have to change that part of fasm that lived unchanged so long time... ;)
Looks like without prefix 66 smsw on new processors
reads 32 bits of cr0 to operand not only msw.
If I'm right then 8001 in upper bits means PG and WP
bit's on CR0 set to 1 and 8000 - PG=1,WP=0 that looks
very much like truth.
I'll try to write KMD to check it.
And some one could write VXD to check it for 9x
(to compare results with 32 bits in Cr0)
reads 32 bits of cr0 to operand not only msw.
If I'm right then 8001 in upper bits means PG and WP
bit's on CR0 set to 1 and 8000 - PG=1,WP=0 that looks
very much like truth.
I'll try to write KMD to check it.
And some one could write VXD to check it for 9x
(to compare results with 32 bits in Cr0)
Then "smsw eax" would be just unprivileged "mov eax,cr0".
All right, I have changed it. The next fasm release will generate smsw opcodes the new way.
BTW: could you add FFREEP if not already present (havent checked it in last releases, and am out home right now)? :)
It's already there.
Then "smsw eax" would be just unprivileged "mov eax,cr0".
Yes,
I wrote KMD, it's cr0 indeed.
test app, kmd and source on heap section
Why have you written that Intel documentation is "obviously wrong"? They're probably just trying to cover both behaviours (the one is from old 80386 docs as I wrote above), and when instruction may fill 16 upper bits of register with upper bits of cr0 or don't modify them at all, the safest description is to say that upper word is undefined. And this description is not wrong. It's just not detailed enough. And you can find much more such "undefined results" in Intel docs - the status of SD, ZF, AF and PF after the MUL instruction is just the first one I can recall right now.
Well, I could take back the term "wrong",
but it wouldn't change informative part of the fact.
The fact is:
In all processor starting from PPlain and upto P4 including
(and also on Althon and Duron models)
smsw reg32 has the same result as mov reg32,cr0.
There are such things with a lot more limited range, yet
Intel specifies them in details.
For example MSRs - Intel worns that they not nesseserily will
be present in future ia32 models, yet it documents them in detail.
The same approach Intel could have taken with smsw reg32,
but it didn't.
I don't want start any antiIntel propoganda :)
Personally I think, that Intel deserves more credits than any company esle
for it efforts and expencies for their products documentation.
Yet the fact remains - in this particular case it's better keep in
mind that though in Intel documentation upper bits of result
of smsw reg32 are "undefiend" - in reality for all models
from PPlain to P4 the upper bits of the result contain upper bits of cr0.
but it wouldn't change informative part of the fact.
The fact is:
In all processor starting from PPlain and upto P4 including
(and also on Althon and Duron models)
smsw reg32 has the same result as mov reg32,cr0.
There are such things with a lot more limited range, yet
Intel specifies them in details.
For example MSRs - Intel worns that they not nesseserily will
be present in future ia32 models, yet it documents them in detail.
The same approach Intel could have taken with smsw reg32,
but it didn't.
I don't want start any antiIntel propoganda :)
Personally I think, that Intel deserves more credits than any company esle
for it efforts and expencies for their products documentation.
Yet the fact remains - in this particular case it's better keep in
mind that though in Intel documentation upper bits of result
of smsw reg32 are "undefiend" - in reality for all models
from PPlain to P4 the upper bits of the result contain upper bits of cr0.
interesting... what about other x86 processors like via C3/eden, crusoe, whatever? And if this is undocumented, how come AMD implemented it as well? :)
1. Is FASM can compile a DOS program?
2. does it have any IDE?
3. Is it have Alloc mem function above 1MB (at DOS)?
2. does it have any IDE?
3. Is it have Alloc mem function above 1MB (at DOS)?
1. Is FASM can compile a DOS program?
2. does it have any IDE?
3. Is it have Alloc mem function above 1MB (at DOS)?
1. Yes, it can compile binary .com or MZ .exe programs. There are some simple examples provided with the DOS/Win32 console distribution.
2. FASMW is a kind of simple IDE - it is for Windows, but you can use it for compiling and executing DOS programs, too. Even Linux programs, altough you won't be able to run them from Windows.
3. What do you mean? If you want to alloc some mem above 1MB in your program, it's rather a question about your programming skills than about the FASM abilities.
Where I can get FASMW? I have download FASM at your site, you put it source code too, is that FASM souce code? .
FASMW is in the Win32 GUI distribution, each distribution contains the full source code for FASM.
Papalov, what is the hexcode for Mov eax,eax and mov ax,ax. Do you have a hex editor ?
Papalov, what is the hexcode for Mov eax,eax and mov ax,ax. Do you have a hex editor ?
Why dont you look yourself in a opcode reference or (with a hexeditor) in a self written example program?
I already do it.
In 16-Bit dissasembler Mov ax,ax is 8BC0 and mov eax,eax is unknown.
in 32-Bit dissassebler mov eax,eax is 8BC0 too and mov ax,ax is unknown.
I already read a tutorial, but because my poor english it causing damage to my brain ( I have headache now) ;)
:stupid:
In 16-Bit dissasembler Mov ax,ax is 8BC0 and mov eax,eax is unknown.
in 32-Bit dissassebler mov eax,eax is 8BC0 too and mov ax,ax is unknown.
I already read a tutorial, but because my poor english it causing damage to my brain ( I have headache now) ;)
:stupid: