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
