[Yhc] YHC, NHC & HEAP_OFF_N1
Tom Shackell
shackell at cs.york.ac.uk
Fri Sep 8 05:46:04 EDT 2006
Hi Kartik,
No it can't be simplified to that, though the reason is a little subtle.
Firstly we have to remember that every heap node follows the same
structure: first we have the node header, then we have pointers to
arguments.
Consider:
HEAP_CVAL show
HEAP_INT 42
PUSH_HEAP
HEAP_CVAL putStrLn
HEAP_OFF_N1 ...
RETURN_EVAL
This builds in the heap
Int 42 stored somewhere else
^
+--------+----|----+--------------+-----------+
| show | | | putStrLn | |
+--------+---------+--------------+-----|-----+
^ |
+------------------------------------+
However:
PUSH_HEAP
HEAP_CVAL putStrLn
HEAP_CVAL show
HEAP_INT 42
RETURN_EVAL
builds
Int 42
^
+-------------+----------+-----|------+
| putStrLn | show | | |
+-------------+----------+------------+
So in the first case we get a an application to putStrLn with it's
argument pointer pointing to an application of show. In the second case
we get an application to putStrLn with it's argument pointer being the
header of show (i.e. a random junk pointer).
Of course we could have something like
PUSH_HEAP
HEAP_CVAL putStrLn
HEAP_PTR_CVAL show
HEAP_INT 42
RETURN_EVAL
where HEAP_PTR_CVAL inserts a pointer to the next item and then writes
that item with a CVAL. Giving
+-------------+-----------+----------+------------+
| putStrLn | | show | ... |
+-------------+----|------+----------+------------+
| ^
+-----------+
But that only works for functions with one argument, so in general you
either end up needing heap offsets (nhc's solution) or a stack (yhc's
solution).
Hope that explains it :-)
Thanks
Tom
Kartik Vaddadi wrote:
> Hello,
> I'm a newbie at yhc & nhc, and I wonder: The nhc bytecode that Tom
> Shackell's presentation gives -- can't it be simplified by eliminating
> the HEAP_OFF_N1 and placing 'putStrLn' before 'show' in the heap, like
> this:
>
> PUSH_HEAP
> HEAP_CVAL putStrLn
> HEAP_CVAL show
> HEAP_INT 42
> RETURN_EVAL
>
>
> Is there some fundamental reason why nhc can't generate such code (which
> yhc does not suffer from) or is this just an artefact of the current
> implementation? Thanks, and sorry if the question was dumb.
>
More information about the Yhc
mailing list