|
Author |
Thread |
 |
|
LocoDelAssembly
Your code has a bug
Joined: 06 May 2005
Posts: 4634
Location: Argentina
|
Code: |
WithSet = {SSE, SSE2, SSE3, SSSE3, SSE4, FPU, FPU287, VMX, SVM, LahfSahf,...} ; The names as documented in CPUID docs plus some identifications for processors prior to CPUID existence (like "FPU")
.ProcessorName with=[comma/space separated elements from WithSet]
|
|
This way the user chooses a processor and he will get a instruction set which is compatible with the most older version of the processor and with the "with=" option he can specify more support. About internal desing I think it could be something like this:
Code: |
; Recieves a list of instructions sets to be enabled
macro enable [args]{...}
.8086 macro [args]{
enable 16bit_real
; process the extra options
}
.286 macro [args]{
.8086
enable 16bit_prot
}
.
.
.
|
|
To clarify, the idea is grouping instructions by feature rather than by processor and then, when you select a processor, the macro for that processor will enable the groups it supports. I don't know about the complexity of this idea though, I hope that it will not be a hard/impossible task. Other forum members please comment 
|
10 Apr 2007, 00:31 |
|
LocoDelAssembly
Your code has a bug
Joined: 06 May 2005
Posts: 4634
Location: Argentina
|
Another idea is forgetting ".cpu" at all:
Code: |
i8086 equ 16bit_real
i80286 equ i8086 16bit_prot
.
.
.
; User code
.enable Pentium4 EM64T LahfSahf
|
|
|
10 Apr 2007, 11:38 |
|
Hayden
Joined: 06 Oct 2005
Posts: 132
|
A #UD exemption handler would be nice. One that emulates invalid intructions. Although you would have to be totaly insane to dedicate enough time to code it.
|
10 Apr 2007, 15:37 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
Hayden wrote: |
A #UD exemption handler would be nice. One that emulates invalid intructions. Although you would have to be totaly insane to dedicate enough time to code it.
|
|
Emulating non-existent instructions isn't so difficult. But emulating 64bit on a 32bit machine using exception handlers would be very difficult indeed because the same encodings are reused.
However, that is not what these macros are intended to do, they are meant to stop the programmer accidentally using an instruction that is non-existent on the target CPU. Much different from using exception handlers and emulation code. Another problem with exception handling is that it is OS specific.
|
10 Apr 2007, 23:15 |
|
asmfan
Joined: 11 Aug 2006
Posts: 401
Location: Russian
|
whoa!!! revolution, thank you very much! nice macroses, didn't know they are developed so far... VERY handy and useful.
_________________ Any offers?
|
21 Jul 2007, 07:54 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
asmfan, You are very welcome, it is nice to get feedback like that, makes me (and all of us, right?) want to contribute more.
|
21 Jul 2007, 09:45 |
|
MCD
Joined: 21 Aug 2004
Posts: 604
Location: Germany
|
LocoDelAssembly wrote: |
http://board.flatassembler.net/topic.php?t=4267
*3DNow and Enhanced 3DNow are disabled by other macros by default (with posibility to re-enable those instruction sets).
|
|
This is bad, because most users (including companies) that need good price/quality CPUs prefer AMD CPUs. This is especially the case here where I live.
Also, for most AMD CPUs up to quiet recently, MMX, 3DNow! and 3DNow extended instructions are more optimized than the SSE instructions, thus simple MMX/3DNow! code may actually run faster than SSE code!
This is especially true for the K6, K6-2, K6-3, Athlon, Athlon XP and some older Athlon64.
_________________ MCD - the inevitable return of the Mad Computer Doggy
-||__/
.|+-~
.|| ||
|
29 Oct 2007, 12:08 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
MCD wrote: |
This is bad ... <snip other irrelevant text>
|
|
I hardly ever see 3Dnow code in any application. If you have 3Dnow code then simply enable the 3Dnow set for that code sction, no problem. Like I said you can always re-enable the 3Dnow instructions in your code sections that use 3Dnow. Remember the macros do not in any way disable 3Dnow in the CPU, they only affect the assembler. It is intended to catch mistaken use of instructions that the target CPU does not support. Once you set the target CPU then you can forget about what is and is not supported and code away, later the macros may catch a 3Dnow instruction that you forget about in your SSE section.
|
08 Nov 2007, 04:17 |
|
windwakr
Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
|
_________________ ----> * <---- My star, won HERE
|
01 Aug 2008, 17:05 |
|
Madis731
Joined: 25 Sep 2003
Posts: 2146
Location: Estonia
|
|
01 Aug 2008, 17:19 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
I have uploaded the file again, see the first message in this thread.
I think the file was deleted due to the hacker incident or the forum upgrade vulnerabilities, not sure which. But if you spot any more missing file from my posts please let me know and I'll upload them again.
|
14 Aug 2008, 21:24 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
LocoDelAssembly wrote: |
Code: |
WithSet = {SSE, SSE2, SSE3, SSSE3, SSE4, FPU, FPU287, VMX, SVM, LahfSahf,...} ; The names as documented in CPUID docs plus some identifications for processors prior to CPUID existence (like "FPU")
.ProcessorName with=[comma/space separated elements from WithSet]
|
|
This way the user chooses a processor and he will get a instruction set which is compatible with the most older version of the processor and with the "with=" option he can specify more support. About internal desing I think it could be something like this:
Code: |
; Recieves a list of instructions sets to be enabled
macro enable [args]{...}
.8086 macro [args]{
enable 16bit_real
; process the extra options
}
.286 macro [args]{
.8086
enable 16bit_prot
}
.
.
.
|
|
To clarify, the idea is grouping instructions by feature rather than by processor and then, when you select a processor, the macro for that processor will enable the groups it supports. I don't know about the complexity of this idea though, I hope that it will not be a hard/impossible task. Other forum members please comment
|
|
Okay, I haven't forgotten about this, I just haven't been able to find a nice solution. But I think that above a close to what I think could work well.
I also intend to upgrade fasmarm for similar functionality, but I will do it in the core assembly code in fasmarm (not with macros as I do for x86).
Some things that still need ironing out is the progressive instruction layers like SSE then SSE2 etc. It wouldn't make sense to enable SSE2 but disable SSE. So a feature list like the above will need some way of distinguishing that and force certain lower layers enabled if higher layers are selected.
|
05 Mar 2009, 05:46 |
|
Tomasz Grysztar
Assembly Artist
Joined: 16 Jun 2003
Posts: 6776
Location: Kraków, Poland
|
Note, that with TASM (and the macros for 8086 I once used, which were made to simulate TASM's behavior) the .8086 setting didn't disallow instructions like "shl reg,count" with count>1, it was just converting them into multiple "shl reg,1" copies. Well, I think that was a nice idea, as it allowed to re-assemble the same code for lower CPU - however it's up to you.
|
05 Mar 2009, 08:14 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
Code: |
.8086
irp instr,sar,sal,rcl,rcr,shr,shl,ror,rol { macro instr val,cnt \{ times cnt: instr val,1\} }
|
|
Is trivial to include.
|
05 Mar 2009, 08:36 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
Hmm:
What will it do? 
|
05 Mar 2009, 08:56 |
|
asmfan
Joined: 11 Aug 2006
Posts: 401
Location: Russian
|
intel's pseudo code for this:
Quote: |
IF 64-Bit Mode and using REX.W
THEN
countMASK ← 3FH;
ELSE
countMASK ← 1FH;
FI
tempCOUNT ← (COUNT AND countMASK);
|
|
does eqtype can handle different sizes of register?
|
05 Mar 2009, 15:24 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
Intel's pseudo code doesn't apply to the 8086.
|
05 Mar 2009, 15:35 |
|
rugxulo
Joined: 09 Aug 2005
Posts: 2239
Location: Usono (aka, USA)
|
Quote: |
.286 macro [args]{
.8086
enable 16bit_prot
}
|
|
Wait, what about 80186 and 80188?? (I read today that no IBM PC ever used one, but they were still used in various machines, e.g. HPLX200 ??)
EDIT: Wait, your old COMPATIBILITY.INC (April 8, 2007) has .186 and .186f, I suspected you didn't overlook it.
P.S. Just to reply to this ...
Quote: |
Also, for most AMD CPUs up to quiet recently, MMX, 3DNow! and 3DNow extended instructions are more optimized than the SSE instructions, thus simple MMX/3DNow! code may actually run faster than SSE code!
This is especially true for the K6, K6-2, K6-3, Athlon, Athlon XP and some older Athlon64.
|
|
It wasn't until the Athlon XP that SSE1 was even fully supported. All Athlon64s support SSE2, though. Original 3dnow! seems to have debuted on K6-2 and Extended 3dnow! debuted in Athlon. No MMXext on either K6-2+ or K6-III+, apparently. (Corrections welcome if that's somehow incorrect.)
|
09 Mar 2009, 00:58 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
The 186 is still active in many embedded products.
Anyone who is involved with embedded programming will know how tempting it is to write instructions that don't exist in their CPU.
|
09 Mar 2009, 01:13 |
|
revolution
When all else fails, read the source
Joined: 24 Aug 2004
Posts: 15646
Location: Thasus
|
Sorry to keep resurrecting this old thread.
I think a nice way to handle it without too much complication is to use a keyword "features"
Code: |
features SSE, SSE2, SSE3, SSSE3, SSE4, FPU, FPU287, VMX, SVM, ...
|
|
As to regards about forcing things like SSE to on when SSE2 is also selected: I see two problems. 1) It makes the macros more complex, and 2) it reduces flexibility. The complexity thing is not really a big issue but I like things to be simple if possible. But the reduction in flexibility may be more important. It is hard to predict what CPU makers will decide in the future. If the macros force on FPU because of the existence of SSE then maybe that is the wrong thing to do on some future CPU that has had the FPU excised. It certainly is possible to remove FPU support and have the OS emulate it so things like this might start happening if it makes the chip cheaper or faster or something. Based upon that idea I think it is best to keep the flexibility and just allow seemingly stupid things like SSE4.2 is on but FPU and other SSE off. Basically programmer beware, if someone wants to be silly with it then fine, that is their problem.
The reason I chose the "features" keyword is that many manuals and discussions talk about having certain features available, also it is short (8 chars) so can be put into the code tables (for the ARM version) easily.
The last part with predefined CPU names (.8086, .80186, etc.) I think should be done with macros (thinking about the ARM version here, obviously the x86 version is all macros). There are just so many different combinations around. Between Intel, AMD, VIA, NEC, HARRIS and others there are a myriad of options. And it seems to me to be unnecessary to define them all. It just adds bloat for no good reason. Once the most common CPUs are defined with the macros then anything special can be added by the user later if needed. Plus it makes a nice demarcation line between the two sets. Easier to upgrade for new chips in the future.
Last edited by revolution on 13 Mar 2009, 00:05; edited 1 time in total
|
12 Mar 2009, 03:14 |
|
|
|
Forum Rules:
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
|
|
|
|
|
|
|
|