[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