These submission notes are duplicated in the motor project since this submission mostly deals with integrating a small scanner/parser into the microcontroller.
The IAR version (5.4_3) caused an Internal Error when compiling the motor.tab.c file generated by bison (and the corresponding motor.yy.c flex file #included in motor.tab.c). By a process of elimination we figured out that this was caused by turning on high optimization for the compiler (under Project/Options). Specifically, unchecking the Loop Unrolling box under transformations will allow you to get past this issue. A corresponding change is about to be made to the motor project to correct this. Note that even when optimized for size, motor.tab.o is still about 34k. This can almost certainly be reduced by using a hand written scanner/parser and should be considered in the future.
Turned on .bin output in the IAR build and note that the motor.bin file is only 12k in size. Will compare how this has grown with the addition of the bison/flex files after this submission. The motor.out file is just over 200k in size but this includes information that is not in the raw execuable.
Note that the IAR build has been modified under Library Configuration from Normal to Full so motor.tab.c that uses the FILE definition will compile. The bison motor.y file, however, has been modified to read input from a fixed buffer rather than a FILE (like stdin) which it normally does. The architecture on the microcontroller is meant to have serial input moved to this buffer and then scanner by the bison code.
Pe111 warnings were supressed in the IAR build due to warnings about unreachable code in the flex/bison code.
Note that the Cygwin command line test version of the motor flex/bison code (motorparsetest) puts its output in motorParse.txt  This file is considered binary by git, probably due to a line ending problem.

Also note that bison.txt has been added back to tracked files in git. Initially it was thought that files like these that can be generated by the build tools are unnecessary, however, it may be useful to track the history of their size as well as content over time. This saves having to regenerate these files, but it's still an open issue of what  to do with things like executable files. From the IAR build it's probably helpful to see how the size changes over time.