Poor man's JIT compiler

[Robert Bernecky]

Ian Lance Taylor wrote:
> Robert Bernecky <bernecky@snakeisland.com> 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.