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

Another idea is forgetting ".cpu" at all:

Code:

i8086 equ 16bit_real i80286 equ i8086 16bit_prot . . . ; User code .enable Pentium4 EM64T LahfSahf

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.

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.

whoa!!! revolution, thank you very much! nice macroses, didn't know they are developed so far... VERY handy and useful.

asmfan, You are very welcome, it is nice to get feedback like that, makes me (and all of us, right?) want to contribute more.

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 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.

Where are the macros???

Moved: http://board.flatassembler.net/topic.php?p=54538#54538

windwakr wrote:

Where are the macros???

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.

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.

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.

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.

Hmm:

Code:

ror ax,-1

What will it do?

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?

Intel's pseudo code doesn't apply to the 8086.

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.)

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.

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.