Thomasz,
how Fasm encodes SMSW regarding 16/32 bit operands?
Posted on 2003-03-03 07:36:07 by The Svin
This instruction always uses 16-bit operands really, and there's only one encoding for it.
Posted on 2003-03-03 08:02:10 by Tomasz Grysztar
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.
Posted on 2003-03-03 08:11:48 by The Svin
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... ;)
Posted on 2003-03-03 08:35:18 by Tomasz Grysztar
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)
Posted on 2003-03-03 08:47:23 by The Svin
Then "smsw eax" would be just unprivileged "mov eax,cr0".
Posted on 2003-03-03 08:50:10 by Tomasz Grysztar
All right, I have changed it. The next fasm release will generate smsw opcodes the new way.
Posted on 2003-03-03 09:06:53 by Tomasz Grysztar

BTW: could you add FFREEP if not already present (havent checked it in last releases, and am out home right now)? :)
Posted on 2003-03-03 09:17:51 by Maverick
It's already there.
Posted on 2003-03-03 09:24:36 by Tomasz Grysztar

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
Posted on 2003-03-03 11:20:44 by The Svin
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.
Posted on 2003-03-04 14:27:10 by Tomasz Grysztar
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.
Posted on 2003-03-05 08:01:05 by The Svin
interesting... what about other x86 processors like via C3/eden, crusoe, whatever? And if this is undocumented, how come AMD implemented it as well? :)
Posted on 2003-03-05 11:54:46 by f0dder
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)?
Posted on 2003-03-08 23:36:01 by realvampire

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.
Posted on 2003-03-09 06:30:15 by Tomasz Grysztar
Where I can get FASMW? I have download FASM at your site, you put it source code too, is that FASM souce code? .
Posted on 2003-03-09 08:32:25 by realvampire
FASMW is in the Win32 GUI distribution, each distribution contains the full source code for FASM.
Posted on 2003-03-09 09:55:09 by Tomasz Grysztar
Papalov, what is the hexcode for Mov eax,eax and mov ax,ax. Do you have a hex editor ?
Posted on 2003-03-09 10:45:03 by realvampire

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?
Posted on 2003-03-09 12:50:02 by bazik
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:
Posted on 2003-03-09 19:23:04 by realvampire