Re: Nop insertion

"BGB / cr88192" <cr88192@hotmail.com>
Wed, 28 Oct 2009 09:11:46 -0700

          From comp.compilers

Related articles
Nop insertion shreyas76@gmail.com (shrey) (2009-10-27)
Re: Nop insertion n.pipenbrinck@cubic.org (Nils) (2009-10-28)
Re: Nop insertion cr88192@hotmail.com (BGB / cr88192) (2009-10-28)
Re: Nop insertion walter@bytecraft.com (Walter Banks) (2009-10-28)
Re: Nop insertion cfc@shell01.TheWorld.com (Chris F Clark) (2009-10-28)
Re: Nop insertion gneuner2@comcast.net (George Neuner) (2009-10-29)
Re: Nop insertion pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-10-29)
| List of all articles for this month |

From: "BGB / cr88192" <cr88192@hotmail.com>
Newsgroups: comp.compilers
Date: Wed, 28 Oct 2009 09:11:46 -0700
Organization: albasani.net
References: 09-10-032
Keywords: architecture
Posted-Date: 30 Oct 2009 11:52:57 EDT

"shrey" <shreyas76@gmail.com> 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?
>
> thanks
> shrey
> [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.


http://en.wikipedia.org/wiki/Native_client




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
related).


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, ...).



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.