Glynn Clements comments the request for the implementation of forward references in an assembly code simulated in Haskell.
If you are assembling into a list, the simplest approach is to perform the assembly phase twice. The first phase generates the list of label/address pairs. The second phase, which has the complete list of label addresses available, performs the complete assembly process. Both phases could use identical code; you just need to ensure that the first phase can assemble a branch instruction for which the label is unknown. Alternatively, you could perform one pass plus a post-processing phase which "fixes" any forward references. This would require either that you can store a label in an assembled branch instructions in place of an actual address, or that you generate a list incomplete branch instructions so that you can go back and fix them. OTOH, if you're actually interpreting the "assembly language" directly, then a forward branch would have to store the label in a "variable" to indicates that instructions are just to be skipped until that label is reached.
This is squeezing the power of a modern lazy language into a soap box... What are the labels good for, hm? Just to identify your chunks of code which are targets of some jumps? Well, use these chunks themselves, their references as your targets; the branching instruction picks up this chunk as the next segment of code to execute. Connect your chunks lazily. Then no forward reference can hurt you. If I may, a shameless personal plug. Look at my paper presented at the last FDPE, a construction of a CPS "assembly-style" interpreter, with lazy code deployment tricks. Jerzy Karczmarczuk _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
