flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Macroinstructions > Macros to choose target CPU

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4634
Location: Argentina

Code:

WithSet = {SSESSE2SSE3SSSE3SSE4FPUFPU287VMXSVMLahfSahf,...; 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 Smile
Post 10 Apr 2007, 00:31
View user's profile Send private message Reply with quote
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

Post 10 Apr 2007, 11:38
View user's profile Send private message Reply with quote
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.
Post 10 Apr 2007, 15:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex

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.
Post 10 Apr 2007, 23:15
View user's profile Send private message Visit poster's website Reply with quote
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?
Post 21 Jul 2007, 07:54
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex
asmfan, You are very welcome, it is nice to get feedback like that, makes me (and all of us, right?) want to contribute more.
Post 21 Jul 2007, 09:45
View user's profile Send private message Visit poster's website Reply with quote
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

-||__/
.|+-~
.|| ||
Post 29 Oct 2007, 12:08
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex

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.
Post 08 Nov 2007, 04:17
View user's profile Send private message Visit poster's website Reply with quote
windwakr



Joined: 30 Jun 2004
Posts: 827
Location: Michigan, USA
Where are the macros??? Question Question Question

_________________
----> * <---- My star, won HERE
Post 01 Aug 2008, 17:05
View user's profile Send private message Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2146
Location: Estonia
Post 01 Aug 2008, 17:19
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex

windwakr wrote:
Where are the macros??? Question Question Question

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.
Post 14 Aug 2008, 21:24
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex

LocoDelAssembly wrote:

Code:

WithSet = {SSESSE2SSE3SSSE3SSE4FPUFPU287VMXSVMLahfSahf,...; 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 Smile

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.
Post 05 Mar 2009, 05:46
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6514
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.
Post 05 Mar 2009, 08:14
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex

Code:
.8086

irp instr,sar,sal,rcl,rcr,shr,shl,ror,rol { macro instr val,cnt \{ times cntinstr val,1\} }

Is trivial to include.
Post 05 Mar 2009, 08:36
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex
Hmm:

Code:
ror ax,-1

What will it do? Wink
Post 05 Mar 2009, 08:56
View user's profile Send private message Visit poster's website Reply with quote
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?
Post 05 Mar 2009, 15:24
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex
Intel's pseudo code doesn't apply to the 8086.
Post 05 Mar 2009, 15:35
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2122
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. Wink

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.)
Post 09 Mar 2009, 00:58
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex
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.
Post 09 Mar 2009, 01:13
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15094
Location: The Unicomplex
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 SSESSE2SSE3SSSE3SSE4FPUFPU287VMXSVM...

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
Post 12 Mar 2009, 03:14
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  Next

< Last Thread | Next Thread >

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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.