How much optimization would you have the program itself do automatically as it compiles? If bit 6 indicated whether or not there was a view field, that would still allow a 63 character name, which would be more than plenty. If you didn't want to add a view field to every definition, you could use a "view field present" bit, implemented like the "immediate" bit in a definition.įor example, in my Forth, the definition name is stored as a counted string, except that bit 7 of the count byte indicates whether or not the definition is immediate, which allows definition name of up to 127 characters.
#Basic compiler how to
which block) the definition starts, but you could use the view field to tell SEE how to handle difficult situations instead. Typically, a view field indicates where (i.e. However, if a word is too complicated for SEE, you could always add view fields to the head.
#Basic compiler code
I'd much rather have the compiled code be efficient than easy to decompile. If the user wants it readable, he'll have to look at the source code I provide that shows what it looks like before these optimizations are carried out.
I know it's taboo in Forth, but there's nothing that says the code is supposed to be readable after being de-compiled, and we are after all talking about internal optimizations. And then in the numeric constant example you gave, the straightlining is not the same as just copying the subroutine's code right there, since the straightlined dolit code no longer has to use the return stack to figure out where to get the data to put on the stack. For example, do you use some kind of number value in the header to compare against a user variable to tell whether to compile the JSR or to straightline the code, based on the size/speed balance chosen at compile time? Of course some would always be straightlined, like INX INX instead of JSR DROP, but there would be a large middle ground where the choice is not necessarily automatic, like chosing between a 7-byte straightlining and a 3-byte JSR with its extra 12 clocks of JSR-RTS overhead. I guess that's partly what I'm getting at. STC is itself just an enabler for the more sophisticated code compilation techniques. From this, interesting thingslike type inferencing can be done, common subexpression elimination, etc - the end result of this form of compilation is machine language that can rival what is produced from C or Oberon compilers, for example. etc.Ī more interesting variation of STC is outright native code compilation, where the compiled code is kept in an ITC-like representation (almost exact, in fact!), but a small bit more detailed. Numeric constants are compiled similarly (JSR dolit, DW literal) OR you can directly inline the constant (DEX, DEX, LDA #value, STA 1,X). A subroutine call is compiled $6C C, address. Compiling STC is just as easy as ITC or DTC. What ideas do you have for how the subroutine-threaded Forth would compile new words into its own dictionary? (I can more-or-less imagine it from my experience with ITC, but I'd probably waste a lot of time re-inventing wheels if I had to implement it myself at this point.) How much optimization would you have the program itself do automatically as it compiles?
0 kommentar(er)
