This is the mail archive of the
mailing list for the GCC project.
AW: basic asm and memory clobbers - Proposed solution
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Joseph Myers <joseph at codesourcery dot com>, David Wohlferd <dw at LimeGreenSocks dot com>
- Cc: Andrew Haley <aph at redhat dot com>, Jeff Law <law at redhat dot com>, "rth at redhat dot com" <rth at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "Paul_Koning at Dell dot com" <Paul_Koning at Dell dot com>, "jakub at redhat dot com" <jakub at redhat dot com>, "rth at gcc dot gnu dot org" <rth at gcc dot gnu dot org>, "pinskia at gcc dot gnu dot org" <pinskia at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing dot org>, "Ian Lance Taylor" <iant at google dot com>, Sandra Loosemore <sandra at codesourcery dot com>, Hans-Peter Nilsson <hp at bitrange dot com>
- Date: Wed, 16 Dec 2015 09:23:41 +0000
- Subject: AW: basic asm and memory clobbers - Proposed solution
- Authentication-results: sourceware.org; auth=none
- Authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de;
- References: <56552209 dot 1020306 at LimeGreenSocks dot com> <56592801 dot 9010606 at LimeGreenSocks dot com> <565DC5F4 dot 6080804 at foss dot arm dot com> <565E1E37 dot 9080609 at LimeGreenSocks dot com> <alpine dot DEB dot 2 dot 10 dot 1512012323160 dot 12604 at digraph dot polyomino dot org dot uk> <565E6862 dot 7070401 at redhat dot com> <566B4BA1 dot 8000509 at LimeGreenSocks dot com> <566BEE35 dot 6070804 at redhat dot com> <566D0CE6 dot 6090905 at LimeGreenSocks dot com> <566E9191 dot 9030106 at redhat dot com> <567092B9 dot 6020703 at LimeGreenSocks dot com>,<alpine dot DEB dot 2 dot 10 dot 1512152238290 dot 10678 at digraph dot polyomino dot org dot uk>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
On 15. Dezember 2015 23:43, Joseph Myers wrote:
> I think the typical use of basic asm is: you want to manipulate I/O
> registers or other such state unknown to the compiler (not any registers
> the compiler might use itself), and you want to do it in a way that is
> maximally compatible with as many compilers as possible (hence limiting
> yourself to the syntax subset that's in the C++ standard, for example).
> Compatibility with a wide range of other compilers is the critical thing
> here; this is not a GCC-invented feature, and considerations for
> deprecating an externally defined feature are completely different from
> considerations for GCC-invented features. Do you have evidence that it is
> now unusual for compilers to support basic asm without supporting
> GCC-compatible extended asm, or that other compiler providers generally
> consider basic asm deprecated?
I totally agree, and I know of another compiler which supports basic asm,
but no extended asm:
The windriver diab compiler does apparently not support extended asm,
instead they offer either "asm string statements" or "asm macros".
This is quoted from http://www.vxdev.com/docs/vx55man/diab5.0ppc/c-embed_.htm
"asm string statements are primarily useful for manipulating data in static variables and special registers, changing processor status, etc., and are subject to several restrictions: no assumption can be made about register usage, non-scratch registers must be preserved, values may not be returned, some optimizations are disabled, and more. asm macro functions described above are recommended instead. See Notes and restrictions below.
An asm string statement provides a simple way to embed instructions in the assembly code generated by the compiler. Its syntax is
asm[ volatile] ("string"[ ! register-list]);
where string is an ordinary string constant following the usual rules (adjacent strings are pasted together, a `\' at the end of the line is removed, and the next line is concatenated) and register-list is a list of scratch registers (see Register-list line, p.154). The optional volatile keyword prevents instructions from being moved before or after the string statement.
An asm string statement can be used wherever a statement or an external declaration is allowed. string will be output as a line in the assembly code at the point in a function at which the statement is encountered, and so must be a valid assembly language statement.
If several assembly language statements are to be generated, they may either be written as successive asm string statements, or by using `\n' within the string to end each embedded assembly language statement. The compiler will not insert any code between successive asm string statements.
If an asm string statement contains a label, and the function containing the asm string is inlined more than once in some other function, a duplicate label error will occur. Use an asm macro with a storage mode line containing a lab clause for this case. See asm macros, p.151. "
asm macros on the other hand are very sophisticated, but totally incompatible with gcc
Also from there:
Examples of asm macros
In this example, standard PowerPC techniques are used to wait on and then seize a semaphore when it becomes free.
asm void semaphore_seize (volatile int *semaphore_p)
% reg semaphore_p; lab loop
! "r4", "r5" /* scratch registers used */
addi r4,r0,1 # token for semaphore
loop: # label replaced by compiler
lwarx r5,r0,semaphore_p # semaphore will be in register
cmpi cr0,0,r5,0 # semaphore free?
bne loop # branch if no
stwcx. r4,r0,semaphore_p # store token in semaphore
bne loop # in case interrupted before stwcz.
So, yes, you are right, the only globally understood form of assembler statements in C is basic asm.