Ian Lance Taylor wrote:
Robert Bernecky <bernecky@xxxxxxxxxxxxxxx> writes:
Roughly, what I've done is to create a set of code fragments,
with labels so that I can determine their address ( via &&label)
and length. E.g.,
topLoad1: reg1 = x[i];
botLoad1:
topLoad2: reg2 = y[i];
botLoad2:
topAdd: regz = reg1 + reg2;
BotAdd:
topStore: z[i] = regz;
botStore:
Then, I have a table of fragment addresses (topLoad1, topLoad2, etc.)
and lengths (botLoad1-topLoad1, botLoad2-topLoad2), and a
(unknown statically) list of fragments to be assembled to build
working code, e.g.:
(Load2, Load1, Add, Store, Loop)
That's an interesting idea but I think it's going to be awfully tough to
get gcc to do this for you. I think it will take you less time overall
if you start with the C code, compile with -S, and pull out the
assembler fragments manually into an assembler source file.
It's tempting to think of C as glorified assembly language, but it
isn't. gcc is not going to make any promises about how the labels are
used in code like this.
People sometimes do something using threading, where each code fragment
ends with something like
goto *code[pc++];
and code is an array of labels for the function being executed.
Ian
Thanks for your quick reply, Ian.
I abandoned the threading idea quite a while ago, as having inadequate
performance for my needs. I thought I had made this apparent in
my original message, but maybe not...
One problem with the tinker-the-assembly-output approach is that
it's labor-intensive, and I'm lazy.
The other problem is that this is a multi-architecture work,
and I don't relish the idea of pasting together a large
army of code fragments on several different hardware architectures
every time we go through a release cycle.
I suppose I could write code to electro-eyeball the .asm file,
and electro-tinker same, but that seems slightly unpleasant.
I may be driven to it, though.
I was hoping there was a way to coerce GCC into being a
bit more well-behaved here.
Robert
ps: I also find the X-86 architecture to be about the
ugliest I have ever laid eyes on, and hope never to
have to actually write any more assembler code for it.
