Mail Archives: djgpp/2000/01/06/12:33:13
Charles Wood <c dot r dot wood @ worldnet.att.net.null> wrote:
> I found the docs, maybe I'm stupid (I hope not) but I'm not getting the %1
> thing.
That '%1 thing' is extended inline assembly. It tells gcc to select a
'good' register for a given value coming from 'outside' the assembly
block, and use that, instead of you fixing it in the code. You write
'%1', and gcc will substitute its own choice of register, and take
care of loading the value into it, or copying the result into the
variable (for %1 in the input and output list, resp.). The benefit of
this is that gcc can still apply some optimization, even in the
presence of that assembly block. E.g., it may still have the input
value in some register, so it doesn't have to load it, or it may keep
the output in its register, and use it, later, without having to store
it to memory, and reload it from there.
The difficult part is when you have to tell gcc what kind of value you
want to store. That's where those 'constraints' come into play, whose
documentation is not really easily found, in the gcc info file ---
it's in the 'porting gcc to a new platform' section. For an easy
start, I'd suggest learning it by reading DJGPP libc code, like the
inlined far*() functions in %DJDIR%/include/sys/farptr.h
And don't forget the reversed order of arguments and other differences
between AT&T and Intel assembly language --- your example is Intel
style, which gcc can't use at all.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -