D
deostroll
Is the c language designed to execute assembly language instructions?
Is it in the standard?
--deostroll
Is it in the standard?
--deostroll
N
Nate Eldredge
deostroll said:
No. It's a common extension, though.
C
cr88192
deostroll said:
I would have to say no...
yes and no...
the standard reserves a keyword ('asm') for use for this purpose, but says
little more on the subject.
the actual syntax of asm blocks, as well as any behavior/... they may
exhibit, is a matter left up to the implementation.
so, as a general rule, I don't use inline assembler...
going OT:
actually, it may seem counter-intuitive, but the most generally convinient
way I have found to use assembler is from a dynamic assembler of mine. FWIW,
at least it allows me to produce the same asm code and have it be usable on
Windows and Linux, and is more ammendable to platform differences than is
statically linked assembler (the problem is one has to worry about OS/CPU
issues in the Makefile, ... whereas from C it is easier to respond to the
issue, and likewise I can gloss over and normalize some of the differences
between Windows and Linux...).
so, alas, it is easier to handle the OS/CPU issue easier in C, than to have
an alternative set of asm files for each OS/CPU combination...
further, there are added benefits:
one can more easily respond to the presence or absence of particular CPU
features, ...
one can compose and assemble code fragments "on the fly", which has a good
deal of uses.
....
but, as a cost, one needs such an assembler, and as another cost, it is
still only really portable to OS's and CPU's one supports...
so, as a general rule:
if it is at all reasonable to do in plain C, do it in plain C...
if one wants ASM for some optimization "wild goose chase", they are better
off sticking with C.
in general, the compiler knows what it is doing...
(I don't use ASM for performance reasons, rather, it is used for the sorts
of things which can't really be done in C...).
K
Keith Thompson
[...]cr88192 said:
Not exactly. The "asm" keyword is listed in Annex J as a common
extension, but such an extension is non-conforming, unless it's
designed to avoid breaking any strictly conforming program. A
conforming compiler must allow to use "asm" as an identifier.
B
Ben Pfaff
cr88192 said:
"asm" is a keyword in C++. Maybe that's what you remember.
C
Chris M. Thomasson
cr88192 said:
FWIW, I use inline asm and/or externally assembled libraries to create
sensitive synchronization algorithms:
http://groups.google.com/group/alt.lang.asm/msg/bec9d5ebda9441da
A
Antoninus Twink
To be honest, that one seemingly trivial difference is enough to make me
use externally assembled asm on the rare occasions I need it. Though I
vaguely remember reading somewhere that gcc is doing an increasingly
good job of accepting Intel syntax - I don't know if it's reached the
stage of being really usable yet?
Exactly. Not one of the GNU folks' better design decisions IMO.
U
user923005
1. Many compilers will allow inline assembly.
2. It's better to use an assember.
I like this one:
http://www.tortall.net/projects/yasm/
C
cr88192
Antoninus Twink said:
I hadn't heard of it, I may go look into this...
yep...
oddly, my compiler doesn't really support inline ASM at present...
then again, if it did, I would probably use the Borland or MS style...
C
cr88192
Antoninus Twink said:
I hadn't heard of it, I may go look into this...
yep...
oddly, my compiler doesn't really support inline ASM at present...
then again, if it did, I would probably use the Borland or MS style...
C
cr88192
<
1. Many compilers will allow inline assembly.
2. It's better to use an assember.
I like this one:
http://www.tortall.net/projects/yasm/
I like NASM...
from what I looked at, I will guess the syntax is about the same between
them...
I also like using my own assembler as well, but FWIW mine is sort of a
subset/variant of NASM's syntax (its macro facilities and a few other things
are different, as I had used a C-style preprocessor, and there are some
other differences, but close enough...).
the most drastic difference though is that my assembler allows multiple
opcodes per line, and various parts of my compiler still use this feature (I
have been gradually eliminating it for sake of making the output more
generic). FWIW, only certain built-in code uses the preprocessor (and not
generally the compiler-produced code).
the reason for a C-style preprocessor is that this is what I had on-hand at
the time, and I have not modified the syntax (I just sort of retrofitted the
C style preprocessor right on top of the assembler...).
ammusingly, my assembler was written originally because NASM would not work
well as a library, but it seems like Yasm addresses this issue. (I had not
looked at Yasm when I wrote mine... but then again, from what I remember I
managed to beat together the assembler in a matter of days, with most of the
work having gone into transcribing the various tables in the Intel manual
into a largish text-file which is used to autogenerate some amount of the
assembler's source code...).
I once started working on a gas frontend, but stopped working on it due to a
lack of personal interest...
or such...
U
user923005
Inline assembly is (IMO) a pretty bad idea in general.
consider:
_asm mov ax, 0xf ; move 15 into the AX register of our 8086
....
_asm mov eax, 0xf; move 15 into the EAX register of our P4
....
_asm mov rax, 0xf; move 15 into the RAX register of our AMD 64
You will notice something strange about the above instructions which
all accomplish the same purpose. The names of the registers have
changed over time. So assembly code ages until it becomes useless.
Back in the bad old days, we had to calculate segments and offsets to
make an address. Now we have easier ways due to the larger address
space. So the techniques change over time. Also, the clever things
like XOR ax,ax to put a zero in ax fastest are not as clever as they
used to be since mov rax,0 is just as good now-days. And the
registers also widen over time. The ax register only held 16 bits.
In short, inline assembly is a mistake. It will obsolete your code
totally in a few years. And when the new whiz-bang chip comes out,
you will be doing a full rewrite.
Once in a great while, it is an evil necessity. But most of the time,
it is a choice you will rue in a few years if you decide to do it now.
IMO-YMMV
L
Lew Pitcher
I agree. That's what the Assembler is for, along with the Linkage Editor.
consider:
_asm LD IX,0x0004 ;
or
_asm BCTR 5,7 ;
The first would only be valid for a Z80 8-bit microprocessor, and the second
would only be valid for an IBM 360 (or followon) mainframe processor.
Neither would assemble if used in a compilation unit on an Intel x86
machine.
And, of course, your example would fail when compiled for a Z80, or a
Z-series or a Dragonball processor.
You can throw source-code portability out the window if you use inline
assembly. Why bother when Assemblers and Linkage Editors (or Dynamic
Loaders) work better and let you leave your C code in a portable form?
[snip]
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
C
cr88192
<
Inline assembly is (IMO) a pretty bad idea in general.
<snip>
but it is pretty damn useful sometimes...
<
In short, inline assembly is a mistake. It will obsolete your code
totally in a few years. And when the new whiz-bang chip comes out,
you will be doing a full rewrite.
Once in a great while, it is an evil necessity. But most of the time,
it is a choice you will rue in a few years if you decide to do it now.
IMO-YMMV
well, I was never saying that inline assembly is portable or lasting...
the point of inline asm is that it can do some things one can't otherwise
do.
so, there may only be a few options:
use inline ASM;
use external compiled and linked ASM;
use some other sort of ASM, or manually compose machine code;
be SOL when the task at hand can't be performed without ASM...
I was not trying to claim that one should go around using ASM just for the
hell of it or anything...
so, use ASM, or be SOL...
one is left to choose the lesser of 2 evils...
granted, in typical app code it is likely rare, if ever, one will need
ASM...
B
BartC
I put inline asm into a language which more or less *was* NASM. The rest of
the language was translated into NASM anyway and the inline stuff (after
some symbol fixups) was just copied over. There was no need to write an
assembler
B
BartC
I never found this a problem. There's quite a few years between 16, 32 and
64-bit machines, so probably they will need new software anyway, and the asm
code will be updated or replaced by something else.
And often my inline asm code exists next to a high-level version that is
commented out (although usually for the purpose of debugging by disabling
the risky asm for something safer).
BTW that's quite a nifty asm syntax; which compiler is that from?
C
cr88192
BartC said:I put inline asm into a language which more or less *was* NASM. The rest
of the language was translated into NASM anyway and the inline stuff
(after some symbol fixups) was just copied over. There was no need to
write an assembler
I wrote an assembler as otherwise it would be an issue using NASM as a
dynamic assembler...
I forget the details, but I remember that I looked over the source at one
point and came to the conclusion that it would have been too much effort to
modify it to work as a library...
F
Flash Gordon
BartC wrote:
<snip>
Not always. Every now and then my company thinks about getting one of
its apps ported to run native 64 bit. It was originally developed as a
16 bit application I believe. Not always the case, but it does happen in
the real world.
The only use I've made of inline assembler was for individual
instructions to do things like enable/disable interrupts which were
single instructions. I wrapped the inline assembler in macros (defined
in a header) which means they *could* easily be replaced by calls to
external functions or different assembler instructions or even disabled
en-masse if required. The overhead of a function call for a single
instruction would have been, for this code, daft.
<snip>
Not always. Every now and then my company thinks about getting one of
its apps ported to run native 64 bit. It was originally developed as a
16 bit application I believe. Not always the case, but it does happen in
the real world.
The only use I've made of inline assembler was for individual
instructions to do things like enable/disable interrupts which were
single instructions. I wrapped the inline assembler in macros (defined
in a header) which means they *could* easily be replaced by calls to
external functions or different assembler instructions or even disabled
en-masse if required. The overhead of a function call for a single
instruction would have been, for this code, daft.
C
Chris M. Thomasson
cr88192 said:
Indeed!
For instance, clever usage of IA-32 (e.g., at&t and/or intel syntax), GCC or
MSVC and POSIX can allow one to create a general purpose read-write lock
that can actually get better performance than native implementations. Try my
little invention against your native OS `pthread_rwlock_t' implementation
(please try on Linux and Solaris/OpenSolaris):
http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/65822
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/61676475dbb8762b
The inline asm actually increases portability wrt two specific compilers.
U
user923005
I still use code I wrote in the 1970s, 1980s, and 1990s.
I do the same thing with ifdefs. We have a large body of code like
that in our big number class (which is a modified version of Moshier's
qfloat).
MS VC++, but the last one does not work (you can't do 64 bit inline
assembly with MS VC++ 2008, or if you can I do not know how to do it.)
C:\tmp>type t.c
int foo(void)
{
int i;
_asm mov ax, 0xf; move 15 into the AX register of our 8086
_asm mov eax, 0xf; move 15 into the EAX register of our P4
_asm mov i, eax; save a copy of eax into our return variable
return i;
}
// For multiple assembly statements, this is cleaner:
int bar(void)
{
int i;
_asm {
mov ax, 0xe; move 14 into the AX register of our 8086
mov eax, 0xe; move 14 into the EAX register of our P4
mov i, eax; save a copy of eax into our return
variable
}
return i;
}
int main(void)
{
int i = foo();
printf("%d\n", i);
i = bar();
printf("%d\n", i);
return 0;
}
C:\tmp>t
15
14