Attached is a macro to help those people that might be programming for older CPU's. I have been using this macro from some time now with my 80286 systems. Especially, the jump code is very useful, ordinary fasm will "optimise" the long conditional jumps with prefixes that the old 286 doesn't support.

Using these macro's you can feel safe programming for any chosen architecture from 8086 up to EM64T (x64) without fear of accidentally including an unsupported instruction. I expect if you are making a program designed to run that supports a certain minimum specification that you can make use of these macro's when your test machine is actually more capable than what you want to support. eg. you might like to support from 80386 and up but your test machine is a P4. with a combination like this you might accidentally slip a bswap in your code and not realise until someone else runs it on their machine and your program crashes.

Anyhow, I hope some of you might find this useful.

nice job, i will highlight this thread, and also include this to FASM package draft.

Okay, now it is sticky.

I have not yet seen the "FASM package draft", I wonder what that is? I would search for it myself but the searching function is broken

it is my try to create some package of useful FASM stuff we produce on board - macros, routines, libraries, include files/equates, examples...

I created example package demonstrating how it all could look like. It is targeted for win32, but packages for linux, linux-amd64, win64 etc... can be created aswell.

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

Beautiful piece of code and very useful aswell

Thanks for sharing!!

just a note: why do you call 64bit architecture EM64T and not AMD64? :]

http://board.flatassembler.net/topic.php?t=4267

I don't know if the difference stills valid but Tomasz said there that EM64T supports 80-bit far jumps while AMD64 don't. Since ".EM64T" does not disable anything* then it can't be renamed to ".AMD64".

*3DNow and Enhanced 3DNow are disabled by other macros by default (with posibility to re-enable those instruction sets).

Thanks for a very useful contribution!

Intel sell 90% of the processors so I just wanted to support the most common. I also disable the 3dnow instructions by default because it seems to me that they are very rarely used and for the most part became quite useless once SSE came out.

However, the macros can be altered for things like LAHF and SAHF etc. Let's discuss and try to make the macros better.

yes, i think that you support both ".em64t" and "amd64". Links in thread loco mentioned should be useful.

Note that both of these should disable something, due to http://www.sandpile.org/post/msgs/20005265.htm

I think that since you define with precision the CPU type (defining not only ".pentium4" but ".pentium4prescott" also), the improvements should go in that way, exact CPU definition so the programmer will be warned if LAHF/SAHF is not supported by a particular CPU implementing EM64T. However I think that ".EM64T" SHOULD NOT be removed but instead adding ".IA32" and those ones allowing the programmer to use the full instruction set available for those arquitectures at the present time.

Intel has 90% of the market? Surely not where the dollar is expensive like where I live, here AMD has more than 10% for sure.

Thanks for your suggestions LocoDelAssembly and vid. I am happy to include these things. But do you have a suggestion as to what to name the LAHF/SAHF variants? Maybe: .EM64T_no_LAHF_SAHF and .EM64T_with_LAHF_SAHF? They are very long and ugly. Did Intel have an official name for the different processors. And also the same question applies for the AMD versions.

I incuded the prescott because it added the SSE3 instructions and there was a clear differece between the two processors. But the LAHF/SAHF thing is much more blurry as to when Intel changed the processors.

Also, to note that I have not included the SSSE3 stuff either, i need to add that as well.

Actually I was shooting from the hip there, but I remember a report saying that Intel still manage to sell 90% of all desktop and laptop processors. I don't have an official source for this information so try not to take it too seriously. I would be happy to be proved wrong if there is a good source that shows the actual breakdown.

http://en.wikipedia.org/wiki/X86-64#Previously

Intel released them with Pentium 4 G1 step. They give some codename to this stepping perhaps.

Something I just realised with the LAHF/SAHF problem is that these instructions are only marked invalid in 64bit mode (by hardware on earlier processors and by software on later processors) but are still valid in 32bit mode. This makes the macros more complicated to implement. eg. Currently the macros don't keep any state except for undoing the last operation. If this were to be implemented into the macros then it will need to keep state and track the mode changes on the fly.

Perhaps it might be best to cater to the lowest common denominator? i.e. disallow cmpxchg16b, lahf and sahf (this way your code works with both AMD and Intel) and allow the programmer to use them selectively by using at least one upper case character. The expectation is that if you put an upper case character in there to use the instruction then that means you already know what you are doing and have already prepared for any possible bad consequences.

With AMD it's a little hard because then always use the Athlon64 name but there are some cores that supports up to SSE3 (like Venice) while others supports only up to SSE2 (like New Castle). A possible sintax could be ".processor_name core=core_name", supposing that Prescott is the core name then it should be used like ".pentium4 core=prescott". The cores sometimes has revision numbers too but I don't remember any example of a core having more instructions in a revision than another, only bug fixes + extentions that has nothing to do with the instruction set.

About a list showing the differencies between cores I haven't got one, I'll try to find one and post it here.

revolution: i think you should overload "use32" and "use64" directives.

I have uploaded a new version at the top of this thread. I have added SSSE3, VME and 64bit_safe macros.

I have not yet decided upon how to handle the processor selection issue. There is a lot of variation among the processors and their associated instruction sets (especially the P4 and Xeon variants). So, for the meantime I have not changed that part. If you have a specific requirement then you will be best to manually use the specific instruction disable macros. I would appreciate if you have any suggestions about how to implement a nice way to select the different processors. However, the original purpose of these macros was not a fine grained selection of processor capabilities, so I think for the meantime the current would suffice in most situations.

I decided to overload the lahf and sahf directly. It just makes better sense to me that way.

I found some info in the wikipedia for the Ahtlon64 series http://en.wikipedia.org/wiki/Athlon_64

About Intel I'm not familiar with the core names so I can't do a google search like I did with AMD which gave me the link to the wikipedia. However, looking at http://www.intel.com/products/processor/pentium4/specs.htm# seems that they don't give a new core name when something is instroduced, just a part number... This is so frustrating that I think the best way will be enabling just the instruction set of the first processor model and then enabling extra instructions separately. For example, not enable SSE3 with ".Athlon64" until some option/macro call says otherwise.

Thanks LocoDelAssembly, I see you also find it somewhat frustrating to properly pin down the core/name/instructions matching. I think your suggestion above is good but how to implement it in a nice way without making the whole thing ugly?