Edit color syntax

Title:

Last edited: 5:39:45 pm on 5 January 2002 by 200-206-140-164.dsl.telesp.net.br

There are several elements in common between Final and Color Forth (*http://www.colorforth.com*):
- use of color and other visual aspects instead of textual syntax
- low level hardware access
- common set of basic primitives
- "open stack" with Reverse Polish Notation execution order
but there are important differences:
- objects and messages are the central concept. Message sending is highly optimized and deterministic (always one clock, not counting cache delays)
- code is stored in executable form (with some "hints" for proper decompilation) and not as source
- code has a "physical" organization in 2D zoomable space instead of an actual physical organization in memory blocks

!!Basic Syntax
An example is probably the best way to introduce the various language elements, so this Smalltalk method
=
= merge: aRectangle
= | minPoint maxPoint |
= minPoint &lt;- origin min: aRectangle origin.
= maxPoint &lt;- corner max: aRectangle corner.
= ^ Rectangle origin: minPoint
= corner: maxPoint
=
is written in Final as:

merge [dup] corner corner max [swap] origin origin min {Rectangle} copy origin! corner!

The yellow tokens translate into "call" instructions (see the *hardware platform* description) while the green tokens are messages to be sent to the value on the top of the stack. The above is only a crude representation of the actual graphical code view. The "{Rectangle}" text would really be an image showing a kind of hyperlink to the actual Rectangle object. We call this a "portal". Portals in the source are translated into a "push literal" instruction.
!!Embedded Code Fragments
The code shown between square brackets would really be inside a box with a different background in the graphical representation. These embedded code fragments are translated in a previous step and then executed when compiling the source they are embedded in. This execution can cause any side effect in the generated code, but the fragments are also stored to help with decompilation later on. Embedded code fragments can also include embedded code to any level of nesting. Since embedded code is executed whenever its outer source is edited instead of at a separate load and compile time, it doesn't have the same range of applications that Forth's immediate mode does.

Note that code fragments are first class objects and that we can have a portal to one instead of embedding it. In that case, a pointer to the code will be pushed on the stack when the outer code executes, which in many ways is the opposite effect of embedding.

The reason why the "dup" and "swap" messages are embedded in the above (not very readable) example is that we don't want to compile instructions to send these messages but we want to actually execute them generating primitive instructions in the code as a side effect.
!!Globals
Each object is like a small Forth dictionary and is shown as a vertical stack of entries like the one above.There is no color or syntax for comments, but the GUI allows text and drawings to be placed anywhere.
!!Implementation
Name lookup happens when the editor generates machine code. All entries with the same name are associated with a global offset. For example, the message PRINT might be associated with the offset 120. This means that if we want to send PRINT to an object, we push its address on the data stack and execute the SEND 120 instruction. This will fetch the word 120 from the object`s code segment and load it into the instruction register. If an object wants to send PRINT to itself,, CALL 120 will have the right effect. Only even offsets are used, so methods with only one or two words (up to six instructions, including RETURN) can be very efficient. Longer methods will include a JMP to the rest of the code in those words.
!!Garbage Collection
Henry Baker's real time treadmill algorithm (*http://linux.rice.edu/~rahul/hbaker/NoMotionGC.html*) is used to minimize the non determinancy in execution times in the system. This has a rather large overhead (two words per object), but makes a lot of things simpler by keeping each object in the same memory position throughout its lifetime. Moving code fragments around would be particularly messy since the processor doesn't have relative jump instructions.

Send e-mail alerts to these addresses upon next save: