OSDev.org

It is my understanding that creating an Abstract Syntax Tree is the last step of the front end of a compiler, and happens right before the conversion to intermediate code. How does in-line assembly fit into an AST? And how does it fit into intermediate code?

Hi,

azblue wrote:It is my understanding that creating an Abstract Syntax Tree is the last step of the front end of a compiler, and happens right before the conversion to intermediate code. How does in-line assembly fit into an AST? And how does it fit into intermediate code?

There isn't one answer - each different compiler may do this in completely different ways.


Cheers,

Brendan

It is my understanding that creating an Abstract Syntax Tree is the last step of the front end of a compiler, and happens right before the conversion to intermediate code. How does in-line assembly fit into an AST? And how does it fit into intermediate code?

Abstract Syntax Tree is typically what you get after parsing, how detailed you want it is an implementation option. So it usually does not happen right before conversion to intermediate code, typically just after parsing is done. You can do some check on this tree, and even do some optimizations like constant folding here.

in-line assembly is part not part of the c grammar, therefore there are multiple ways to do it. For instance i can think of
(1) Add an additional asm statement to the grammar -> This ways it becomes part of the AST. and apply the seperate rules for this AST node.
(2) Have a compiler specific way of doing it. When you see an asm keyworkd, put everything into a buffer and hint the other layers what to do.

PS: I am not a compiler engineer, Most compilery thing i have done is report bugs to compiler teams and say you folks messed up .

--Thomas

Thomas wrote:in-line assembly is part not part of the c grammar...

Well, the asm() keyword is mentioned in section J.5 "Common Extensions".

Personally though, I would go for __asm() or __asm__(), symbols which are "reserved for the implementation", whereas asm() is not strictly conforming.

As ASM targets the machine directly, i.e. there is nothing "intermediate" about it, whereas C targets an abstraction. You will need hints for the compiler to avoid breakage at the boundary (registers clobbered by the ASM), and a way to feed data from the abstraction to the machine and back.

Actually, I think the GCC __asm__ extension does a reasonable job.

If you can get your compiler to auto-deduce e.g. the clobbered registers, even better. But, to be quite honest, I don't really see the use-case here. The need for inline ASM is not that big...