Mill Computing, Inc. Forums The Mill Tools Simulators I was at it again. Reply To: I was at it again.

Ivan Godard
Post count: 689

Yes, the ‘%’ and ‘^’ operators are overloaded, as is the ‘,’ operator. C++ lends itself fairly well to the creation of Application Specific Languages such as our conAsm assembler format.

Mill bundle execution extends over three physical cycles on which seven phases are overlain. Each op has a spec which tells in which phase each argument is evaluated (which may differ for different args), and which phase it drops its results. If the drop phase of one op is earlier than the eval phase of another then data can be passed among ops in the same bundle; that’s what’s happening in the lea->call dependency you noted.

The listing includes a comment for each bundle that shows the belt events that happen during the cycle that contains the opPhase of that bundle. These comments are to help the reader understand what is going on, because so much is happening all at once. For example, the comment on the bundle with the call is “// V%0 ^%1 ^%0”. This says that (in that cycle) %0 was dropped (“V”) and %0 and %1 were evaluated (“^”). Looking at the ops, you see that V%0 came from the rd(), while ^%1 went to the call0() and ^%0 to the retn(). The items in the comment are in time order, so a ^%n can see and use a V%n to its left or in the comments of earlier bundles. Hence the retn can use the result of the rd, and so on.

As for the rest, the “section” stuff is organization material for the linker, and is irrelevant if you are not doing separate compilation. The “main” at the top and “return” at the bottom is to make the whole thing into an executable C++ program. In the assemble step in the tool chain, that C++ program is compiled and executed. The execution builds an internal representation of the program and processes it to build ELF binaries or the source which when compiled is the simulator for the program. We’re working on going direct from specializer to binary, making the assembler step optional, but that’s not up yet.

BTW, it’s always wise and prudent to ask 🙂 Most companies seem to feel that it’s not prudent to answer, but we differ.