Tool Chain for additional languages
rokicki
Posts: 1,000
I'm thinking of defining and putting together a tool chain for additional languages.
I'll probably start with a simple BASIC compiler, but I want it to be able to link in other
objects in SPIN. I also want to add debugging support.
In order to do this, I need to define a file format for symbols. I can write a simple
script that reads the spin code and extracts external object declarations, variable
declarations, and method declarations, and builds symbol offsets and puts them in an
external linkage/debugging file.
I've got a couple of technical concerns, though:
1. I would need a binary format *and* a spin file for every object included.
Is there some way to automate the Spin IDE (for instance, call it from the
command line with /compile foo.spin /output foo.binary or some such)?
2. I'm a bit concerned about the way the IDE searches for and finds spin files
based on object names in the source; I'd need to duplicate this code in
my linker.
I'm sure others are thinking along these lines; what have you guys found?
Also, it looks like the binary object format is sufficiently defined that we can
pretty clearly rearrange things as they are. (Essentially, we can distinguish
data from code for the Spin section, and [noparse][[/noparse]for now] simply always include the
entire code section.)
Anyway, I just wanted to mention that I'm looking at all this stuff now, and if
anyone has already done it, or is in the process of doing it, let's discuss it all
here.
A "simple C" compiler should really be quite easy to put together, and it is
*much* more useful if it can directly use the library of objects that have already
been created in Spin.
I'll probably start with a simple BASIC compiler, but I want it to be able to link in other
objects in SPIN. I also want to add debugging support.
In order to do this, I need to define a file format for symbols. I can write a simple
script that reads the spin code and extracts external object declarations, variable
declarations, and method declarations, and builds symbol offsets and puts them in an
external linkage/debugging file.
I've got a couple of technical concerns, though:
1. I would need a binary format *and* a spin file for every object included.
Is there some way to automate the Spin IDE (for instance, call it from the
command line with /compile foo.spin /output foo.binary or some such)?
2. I'm a bit concerned about the way the IDE searches for and finds spin files
based on object names in the source; I'd need to duplicate this code in
my linker.
I'm sure others are thinking along these lines; what have you guys found?
Also, it looks like the binary object format is sufficiently defined that we can
pretty clearly rearrange things as they are. (Essentially, we can distinguish
data from code for the Spin section, and [noparse][[/noparse]for now] simply always include the
entire code section.)
Anyway, I just wanted to mention that I'm looking at all this stuff now, and if
anyone has already done it, or is in the process of doing it, let's discuss it all
here.
A "simple C" compiler should really be quite easy to put together, and it is
*much* more useful if it can directly use the library of objects that have already
been created in Spin.
Comments
2) I wouldn't duplicate this. The file name is given in double quotes (without the .spin extension) in the OBJ declarations. I believe the directory search order is: a) top level - where the source file is located, b) library level - where the IDE is located. I'd allow linker options for local and library searches with defaults to the same.