Re: dword ptr in Intel x86 assembler
Re: dword ptr in Intel x86 assembler
- Subject: Re: dword ptr in Intel x86 assembler
- From: Eric Albert <email@hidden>
- Date: Sun, 14 Aug 2005 17:21:08 -0700
On Aug 14, 2005, at 4:37 PM, Steven Kortze wrote:
I've been working on some Mac x86 support in an open source fractal
project. The project has some x86 assembler for FPU, SSE and SSE2
routines. However, the gcc x86 tools choke on just about anything with
"dword ptr" in it. I've seen some postings on the net mentioning that
the gcc tools has some problems with it. Based on this, I would
presume that it is a known problem. Is there any workaround for it?
For reference, I am using an asm code block (i.e. asm { xxx xxx }) in
a *.cpp file. With the dword ptr code active (not commented out), I
usually get a message that cc1plus crashed when I do a save.
In the x86 world, there are two different flavors of assembly syntax.
"dword ptr" is Intel's assembly syntax. The GNU tools (gcc, GNU as,
etc.) use AT&T syntax. You can find a quick primer on the differences
between Intel and AT&T syntax at
<http://www.imada.sdu.dk/~kslarsen/Courses/dm18-2005-spring/Litteratur/
IntelnATT.htm>.
Just as important as this is that gcc's inline assembly syntax is very
different from Visual C++'s syntax. In particular, gcc requires that
you tell it which registers you're changing.
Instead of using the actual assembler code, I have built some code
that uses the x86 SSE intrinsic functions. As long as I turn on
compiler optimizations, that seems to work pretty well in terms of
functionality and performance. Are there any workarounds for the dword
ptr issue?
I'd strongly suggest using the intrinsics. They'll work out best in
the long run, and you'll be able to have only one version of your code
for all x86 platforms.
Hope this helps,
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden