|Nop insertion email@example.com (shrey) (2009-10-27)|
|Re: Nop insertion firstname.lastname@example.org (Nils) (2009-10-28)|
|Re: Nop insertion email@example.com (BGB / cr88192) (2009-10-28)|
|Re: Nop insertion firstname.lastname@example.org (Walter Banks) (2009-10-28)|
|Re: Nop insertion cfc@shell01.TheWorld.com (Chris F Clark) (2009-10-28)|
|Re: Nop insertion email@example.com (George Neuner) (2009-10-29)|
|Re: Nop insertion firstname.lastname@example.org (Pertti Kellomaki) (2009-10-29)|
|From:||"BGB / cr88192" <email@example.com>|
|Date:||Wed, 28 Oct 2009 09:11:46 -0700|
|Posted-Date:||30 Oct 2009 11:52:57 EDT|
"shrey" <firstname.lastname@example.org> wrote in message
> This is both an architecture and compiler question.
> Are there inorder architectures that need precise number of nops
> inserted between operations. If so, how does a compiler guarantee
> that ? I am especially thinking of producers and consumers in faraway
> basic blocks. Any pointers to any exiting work?
> [There have been a few, it's typically done by the assembler. -John]
There is also a project known as 'Native Client', which has very
specific code alignment rules. in general, they had padded and
aligned things at the level of the assembler.
Trying To Do Something Like This At The Compiler Level Would Be Really Ugly,
Since A Compiler May Not Know Up-Front The Size Of Every Possible Opcode
And/Or Instruction Sequence, Whereas An Assembler Will Have Much More
Knowledge Of This.
I am currently working on something vaguely similar, except using stock x86
and interpretation (and maybe later, dynamic translation) instead (well, and
apart from the difference that I am not working on anything browser
in my case, I am using x86 machine code as a stand-in for a bytecode,
where essentially it would serve a similar role to how many VM's use
bytecode (and is not confined to x86-based hosts).
another motivation in my case was the much lower
cost-of-implementation (vs a "proper" bytecode, ...), given my
codebase already had lots of x86-related facilities, ... (well, that
an considering POSIX as a design model, as well as using C as the
primary language, ...).
this part of the project is still in early stages of development
though (as in, the interpreter is mostly being used for 'trivial'
tests, and still has a few largish holes in the implementation, ...).
Return to the
Search the comp.compilers archives again.