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.
_______________________________________________
Yhc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/yhc
