Difference between revisions of "Talk:GenAsm (language)"

Latest revision as of 17:03, 1 January 2015

01Jan2015: Ivan has posted a bit more explanation about labels, branching and label-associated operands in: [1]

27Dec2014: A first attempt at a discussion page; please bear with me. -- LarryP

in a recent forum post, Ivan has given us a short sample of GenAsm code that reveals the basics of labels and branching. See [[2]]

Here is that example and explanation:

label w lab; if (b eql 0) then 17 go lab fi; …. F(x,y,z) lab: + a -: c;

Here if b is zero then control transfers to lab carrying the data value of 17. Otherwise execution continues until the function call on F, whose return value become the fall-through value at the join at lab. However control reaches lab, the data is added to a and that is bound to c.

I see a number of interesting (at least to me) things in this short example.

• The if .... fi construct is syntactic sugar on top of labels and conditional branches thereto.

• Similar syntactic sugar for (at least some kinds of) loops is in the works.

• "Transfers to and fall-throughs into a join carry data. The widths of the carried data is declared in the labelDef, and the count of carried operands must fit on the belt."

It's not clear to me whether the data associated with a label is supposed to represent the entire belt contents (hope not) vs. what the N possible branches add to the the belt, before reaching the label/join. Absent the label declaration "label w lab;" I would have expected the literal 17 to have byte width, rather than (32-bit) word. It may be that the assembler is smart enough to automatically coerce that literal into the type specified by the label. (Or not?)

When coding in genAsm, we don't yet know which Mill member(s) this code will be executed on, so how can we tell if the count of carried operands will fit on a given member's belt, or not? Unclear to me how this will work.

• the example has identifiers for variables (like a, b, and c), but I can't tell whether these refer to belt-resident operands, stack-resident, or elsewhere out in memory. Similarly, the scope of variables is as yet unclear, though I expect they are scoped.

Clearly, genAsm is in flux, but it's starting to look like a tool that could be used to hand code more complex examples than have previously been made public. An interpreter for Forth (or similar) has been proposed by forum user tomberek.