File ChangingXcom.html    Author McKeeman    Copyright © 2007    index

Changing xcom

First things first; if you are going to change xcom, pick a new name for your version.

Typically one extends a language like xcom by adding some new construct. The sequence of change-events is important, if for nothing else, to avoid a big bang of many changes before feedback is available. The supposition here is that some small addition will be made to X.cfg. This change may, or may not, require changes to further modules before xcom can run again.

In some cases the sequence below will not be best. For instance, if there is a large runtime package to be integrated, it might be best to do that first.

Recommended Order of Changes

1. Do not forget the warm up exercise.
2. X.cfg (add to the X context-free grammar)
3. Cfg.m (run makeCfg always, but rarely tweak the cfg object)
4. Lexer.m (change only if a new token type -- such as string -- has been added)
5. Parser.m (change almost always, whenever a cfg rule is changed)
6. Tree.m (change almost never, building a syntax tree is standard)
7. Symbols.m (change almost always, to deal with new tree nodes)
8. Generator.m (change almost always, to deal with new tree nodes)
9. EmitX86.m (change almost always, to deal with new semantics)
10. AsmX86.m (change only when a new CPU instruction is added)
11. EmulateX86.m (change only when a new CPU instruction or X builtin is added)
12. Runtime (change whenever a new C runtime routine is added)

Testing xcom

xcom is arranged so that small changes can be tested immediately. Test often. Update tests as you go.