Re: questions about gcalc front end

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17 September 2010 14:54, Andre-Marcel Hellmund <mail@xxxxxxxxxxxxxxxx> wrote:
> Hey Asma,
>>
>> I tried to compile a .gcal file using gcalc fe.
>> test.gcal contains only x=2;
>>
>> [root@is010178 Gcalc]# /usr/local/bin/gcal -S -fdump-tree-all t.gcal
>> calc1: note: primary: INTEGER
>> calc1: note: expression: primary
>> calc1: note: expression: expression '=' expression
>> calc1: note: statements: statements stmt
>>
>
> Great that it works without any errors so far ;-)
>>
>> when I look at gimple and generic IR I notice that it is not the same
>> structure
>> (as Philip said).
>> I red last year papers in the GCC summit saying that gimple and generic
>> have the
>> same grammar with some restriction in gimple: only 3 adress structure are
>> allowed, ...
>> but I can see here that Generic is a composed of tree codes
>> (function_decl,
>> integer_cst, ...) however gimple is a set of gimple instruction that are
>> different from tree code (gimple_assign, gimple_bind,... )
>>
>
> I'm not sure which papers (which year?) you read, but yes, there are some
> older papers which state that GIMPLE and GENERIC share the same structure.
> From what I know, this was true for the first versions of GIMPLE, it was
> redesigned in 2008 to be tuple-based instead of tree-based. The single
> GIMPLE-tuples however then use the GENERIC (sub)trees as operands.
>>
>> My questions are:
>>
>> 1. Is this difference due to changes applyed to Gimple that becomes based
>> on
>> tuples rather than trees ?
>>
>
> Yes, I think so ...
>>
>> 2. what is the function (in the gcalc fe) that transform generic to gimple
>> ?
>>
>
> The main function for the transformation of single functions is
> gimplify_function_tree, while the real worker function is gimplify_expr
> (attention: this function is very complex!!!)
>>
>> 3. when I want to generate the executable from x=2 (I omit the -S option)
>> I get
>> this error (linker error)
>>
>> [root@is010178 Gcalc]# /usr/local/bin/gcal -fdump-tree-all t.gcal
>> calc1: note: primary: INTEGER
>> calc1: note: expression: primary
>> calc1: note: expression: expression '=' expression
>> calc1: note: statements: statements stmt
>> /usr/bin/ld: cannot find -lgcalc
>>
>
> Ohhh, thanks for catching this. The gcalc demonstration front-end is still
> work in progress and we need to improve the runtime-library interaction. It
> seems that the runtime library wasn't built. As a workaround, do
>
> # /usr/local/bin/gcal -fdump-tree-all t.gcal -v
>
> And then copy+paste the ld/collect2 command while omitting the -lgcalc. This
> should then work. We'll obviously improve this ;-)
>

Hmm maybe i need to look at the compiler driver again, though it works
on my end fine well on my laptop haven't installed it on my desktop.
The way i like to think of the two IR's is that GENERIC is a Directed
Acyclic Graph as in an expression such as <x = 1 + 2;> will produce
something like, you may want to look at our front-end documentation in
the internals manual within the gcalc git branch (its in
gcc/doc/languages.texi)

  =
/   \
x   +
    /  \
   1    2

So its a more semantic level operation, where as Gimple will produce:

t1 = 1 + 2
x = t1

Well this is highly simplified but its the way i tend to think of them.

--Phil


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux