Re: C-style assembly

[Doug Evans <dje@transmeta.com>]

Shehryar Humayun writes:
 > > No effort has been put into supporting C style
 > > assembly language.
 > Is this due to lack of expression in RTL or is it the
 > cgen implementation that has been constrained with
 > supporting only a specific assembly syntax (i.e.
 > mnemonic opr1, opr2)?

It's due to lack of desire for supporting arbitrary (in the
general case) assembler syntaxes.  It's time best spent elsewhere IMO.

 > Correct me if I am wrong, I am asking this because I
 > think that if the cause is lack of RTL's expression,
 > then the escape hatch of emitting c-code in .cpu files
 > can be used;

I don't understand how this is useful.
The issue here is providing something to gas that let's it _parse_
(pseudo) c-code (i.e. the incoming assembly).
Also, RTL isn't really relevant here.  What is relevant is
the assembler syntax string that can be specified along with the RTL.
Or maybe that's what you meant?

 > and if the cgen's implementation is a
 > constraint, then the .scm files can be manipulated to
 > understand c-code, right?

There are two related issues here.
The first is how the assembler syntax is represented in the .cpu file.
The second is the assembler syntax that gas accepts.
Normally these issues are the same, the assembler syntax in the .cpu
file is just a template of the gas syntax.
I only mention this as maybe there's a way of solving this by
having a different assembler syntax in the .cpu than what gas accepts.

More to the point ...
There's a fundamental property of all gnu tools that one
always takes into consideration when doing design: target specific
code does not belong with target-independent code.
[there are exceptions, though even those are generally treated carefully]

In other words, if special code is needed to support a particular target,
then that code belongs with the rest of the code associated with
that target, and not with the core of the tool itself.

In this case, I _think_ there isn't enough of a compelling reason
to add a whole bunch of code to cgen proper just to support C-style
assembler syntax.
The best way to engineer a solution here is to keep as much of the
code out of the .scm files as possible and instead keep it with the target.

 > > If you want to use cgen's assembler support,
 > > I suggest writing the .cpu using "normal" assembly
 > > syntax and
 > > write a separate program(/library) that converts
 > > C-style to normal-style.

Doing this is one way of keeping all target-specific code with
the target and out of cgen proper.

Maybe there is a reasonable way to add C-style assembler syntax support
directly to cgen.  I fear however that it's a slippery slope and best
avoided.  One target's c-style assembly syntax isn't necessarily
similar to another's, and I _think_ supporting all of them in cgen
proper will lead to a big mess really quick.  Best to solve this
problem outside of cgen.