Same to you, Steve. I will take a look at the Homespun source (it's been a while) to see what I might be able to do. No promises beyond that.
Thanks Michael. Having #include built-in with Homespun and BSTC would allow much flexibility. I guess it is practical to use an external CPP for users who need it. Even some of the advanced users here don't get it though (and are bias blind).
BTW, I used Reflector to look at your code and it's interesting that you use a different class for each bytecode. That's a good way to do it with IDL though. The only thing that stops me from recompiling is some invisible methods you're using that seem to be associated with Hashtable.
Michael, thank you very much for putting time into this.
That seems to work fine for a simple program. It even adds PASM code to the .lst file where the #include statement is added. Perfect
I did run into one annoying factor though which I believe I've seen before. If I #define DSYMBOL in one spin file that uses other spin objects, DSYMBOL doesn't seem to be passed to other files ... see example below which fails. Is it possible to pass the DSYMBOL down to the other objects?
' begin testinc.spin
#define USE_PASM
OBJ x : "testobj"
PUB main
x.start
repeat
' begin testobj.spin
PUB start
cognew(@entry,0)
#include "pasm.spin"
' begin pasm.spin
#ifdef USE_PASM
dat org
entry
mov dira,#0
jmp #entry
#endif
Just one more thing while you're thinking about this (sorry if I ask too much). Is it possible to allow a -D list of arguments to the homespun command line to use for compiling?
I did run into one annoying factor though which I believe I've seen before. If I #define DSYMBOL in one spin file that uses other spin objects, DSYMBOL doesn't seem to be passed to other files
Right, that's the issue Cluso mentioned a few posts ago. One step at a time.
Attached is version 0.27y (rename to .exe). This one should pass #defined symbols down to sub-objects. You can also define symbols on the command line with -D <symbol> (e.g. homespun027y blah.spin -D DEBUG -D LMM). Note that option -d (lower-case) does something else (generates listing file).
This is an experimental version of Homespun. Download only if you want to test the new #define functionality. Find bugs soon, while I'm still thinking about the code.
This is an experimental version of Homespun. Download only if you want to test the new #define functionality. Find bugs soon, while I'm still thinking about the code.
Looking good so far. I see lots of defines popping up in the compiler output in various sources. More testing tomorrow ....
Wait for 0.28 to incorporate into Catalina. Who knows if these experimental versions really work. I've only done powderpuff testing. I expect bug reports.
This one should understand Windows-style paths (\) and non-Windows (/) for the SPINLIB environment variable and -L command-line option. To increase your chances for success, add the appropriate separator at the end:
-L \foo\blah\ or -L /foo/blah/
New in this version: FILE and #INCLUDE directives will search libraries if the file isn't in the current directory.
Also new: TESTN instruction added (thanks, Hanno!).
Thanks Michael for this excellent compiler!
The latest betas of ViewPort and 12Blocks now use HomeSpun to compile spin code. To date I'm only taking advantage of HomeSpun's support for multiple libraries. I'm very excited about conditional compilation and include.
Hanno
All right, after exhaustive testing <yeah, right> I've posted version 0.28 at the top of this thread. The only change from 0.27z is jazzed's last request and the version number.
I kinda feel I should apologize for taking soooo long to add #include. People have been requesting it for a long time. I avoided it because I thought it would be very difficult, given Homespun's design (or lack thereof). It turned out to be not that hard (I think the fact that I hadn't looked at the code in months gave me a little distance to see a solution), so thanks for that last push, Steve!
Is it possible for HomeSpun emit just the compiled DAT section of a Spin file as a binary blob without any of the spin stuff in it?
I suppose so. What should happen in the case of sub-OBJs, when there'll be multiple, non-contiguous DAT sections? Write just the first, write them all, error out, or something else?
I suppose so. What should happen in the case of sub-OBJs, when there'll be multiple, non-contiguous DAT sections? Write just the first, write them all, error out, or something else?
Thanks Sapieha, those are good ideas. However, I decided to follow BST's lead and just write the DAT of the top object. As of version 0.29, you can invoke Homespun with -c on the command line to write the DAT section to filename.dat.
Sorry, I seem to have missed your question re: emitting DAT multiple sections.
I think your solution and BST's is perfectly acceptable. i.e. Just ignore the problem and write out the first DAT section you come across.
I suspect that the vast majority of objects follow a simple model of: some spin code to get a cog started plus access methods thereafter, plus a single DAT section for the work to be done in a COG.
For sure if anyone comes up with at more complicated case they actually want to extract for use with C or whatever they will soon let you know:)
Looks like this will make the ZOG interpreter much more manageable, given all the different external memory platforms it must support.
This is a good feature. I can almost completely replace BSTC with Homespun in ZOG now.
There is one problem though. As you can see the binaries endian orders are different. It would be nice if they were the same. There are ways around this with the superior GNU make, but not others. Just one idea: you could have -C for big endian -vs- -c which now produces little endian.
$ od -Ax -tx1 TV.dat.homespun
000000 5c 2a fe a0 0a 36 fe a0 15 2d be 5c 02 36 fe e4
000010 5c 2a fe a0 01 6a 7e 61 fc f6 8d a0 02 6a 7e 62
...
$ od -Ax -tx1 TV.dat.bstc
000000 a0 fe 2a 5c a0 fe 36 0a 5c be 2d 15 e4 fe 36 02
000010 a0 fe 2a 5c 61 7e 6a 01 a0 8d f6 fc 62 7e 6a 02
...
BTW: Would you consider adding the common "#ifndef symbol" syntax ?
BSTC is writing out big-endian?? That doesn't sound right, and I can't repro it here. My copy of BSTC is pretty old, though (0.14)... but big endian just doesn't make sense.
BSTC is writing out big-endian?? That doesn't sound right, and I can't repro it here. My copy of BSTC is pretty old, though (0.14)... but big endian just doesn't make sense.
I'm sorry. You're right: just using bstc.linux -c produces the right order. The dump I had was from a file apparently and unexpectedly manipulated by the objcopy program. For some reason the ZOG library makefile objcopy command is swapping binary source bytes. ....
Comments
Same to you, Steve. I will take a look at the Homespun source (it's been a while) to see what I might be able to do. No promises beyond that.
BTW, I used Reflector to look at your code and it's interesting that you use a different class for each bytecode. That's a good way to do it with IDL though. The only thing that stops me from recompiling is some invisible methods you're using that seem to be associated with Hashtable.
N.B.: This is an experimental version of Homespun. Download only if you want to test early #include functionality.
Edit: Removed 0.27x; see 0.27y a few posts down.
That seems to work fine for a simple program. It even adds PASM code to the .lst file where the #include statement is added. Perfect
I did run into one annoying factor though which I believe I've seen before. If I #define DSYMBOL in one spin file that uses other spin objects, DSYMBOL doesn't seem to be passed to other files ... see example below which fails. Is it possible to pass the DSYMBOL down to the other objects?
' begin testinc.spin #define USE_PASM OBJ x : "testobj" PUB main x.start repeat ' begin testobj.spin PUB start cognew(@entry,0) #include "pasm.spin" ' begin pasm.spin #ifdef USE_PASM dat org entry mov dira,#0 jmp #entry #endifJust one more thing while you're thinking about this (sorry if I ask too much). Is it possible to allow a -D list of arguments to the homespun command line to use for compiling?
Thanks a ton!
--Steve
Right, that's the issue Cluso mentioned a few posts ago. One step at a time.
This is an experimental version of Homespun. Download only if you want to test the new #define functionality. Find bugs soon, while I'm still thinking about the code.
Edit: Removed attachment.
Thanks for all your work - I may not have time to incorporate this into the next version of Catalina, but it will certainly go in the one after that!
Ross.
Wait for 0.28 to incorporate into Catalina. Who knows if these experimental versions really work. I've only done powderpuff testing. I expect bug reports.
m
I thought I would try replacing BSTC for some projects since BSTC does not have the #include feature.
I'm having an issue with libraries running with mono.net. My libraries are in /home/user/spin
Should this work?
mono /home/steve/bin/homespun027y.exe spinfile.spin -b -L /home/user/spin
If I copy the library file to the working folder, everything works fine.
Thanks.
--Steve
At the moment, #include looks for files only in the working directory (unless the filename includes a path); could that be what's wrong?
The compiler is not able to find an OBJ file in my specified library path.
The problem I see is not related to #include.
Edit: Never mind. I thought we could fake it out, but it looks like I have to make a fix (for / vs \). Guh. New version coming soon.
This one should understand Windows-style paths (\) and non-Windows (/) for the SPINLIB environment variable and -L command-line option. To increase your chances for success, add the appropriate separator at the end:
-L \foo\blah\ or -L /foo/blah/
New in this version: FILE and #INCLUDE directives will search libraries if the file isn't in the current directory.
Also new: TESTN instruction added (thanks, Hanno!).
Edit: Removed attachment.
Yay!
And a more complicated example ....
If there was any one wish left to be granted, I would wish for Homespun to print the final image binary size before writing the file.
The latest betas of ViewPort and 12Blocks now use HomeSpun to compile spin code. To date I'm only taking advantage of HomeSpun's support for multiple libraries. I'm very excited about conditional compilation and include.
Hanno
It currently says "writing blah.binary" at the end; you want it to say "writing 108 bytes to blah.binary"?
Knowing how close I am to using 32768 bytes for normal size programs is of great benefit. It also helps identify other issues during development.
I kinda feel I should apologize for taking soooo long to add #include. People have been requesting it for a long time. I avoided it because I thought it would be very difficult, given Homespun's design (or lack thereof). It turned out to be not that hard (I think the fact that I hadn't looked at the code in months gave me a little distance to see a solution), so thanks for that last push, Steve!
Anyway, it seems to be working, so have at it.
Is it possible for HomeSpun emit just the compiled DAT section of a Spin file as a binary blob without any of the spin stuff in it?
I suppose so. What should happen in the case of sub-OBJs, when there'll be multiple, non-contiguous DAT sections? Write just the first, write them all, error out, or something else?
If possible write every DAT section that has ORG 0 as separate file.
Second possibility Write every section as next 2k boundary in same file.
Version 0.29 attached to top post.
Sorry, I seem to have missed your question re: emitting DAT multiple sections.
I think your solution and BST's is perfectly acceptable. i.e. Just ignore the problem and write out the first DAT section you come across.
I suspect that the vast majority of objects follow a simple model of: some spin code to get a cog started plus access methods thereafter, plus a single DAT section for the work to be done in a COG.
For sure if anyone comes up with at more complicated case they actually want to extract for use with C or whatever they will soon let you know:)
Looks like this will make the ZOG interpreter much more manageable, given all the different external memory platforms it must support.
Also looks like Jazzed is on that case already:)
This is a good feature. I can almost completely replace BSTC with Homespun in ZOG now.
There is one problem though. As you can see the binaries endian orders are different. It would be nice if they were the same. There are ways around this with the superior GNU make, but not others. Just one idea: you could have -C for big endian -vs- -c which now produces little endian.
BTW: Would you consider adding the common "#ifndef symbol" syntax ?
Thanks for your efforts.
--Steve
Almost home
I just copied the #ifdef code and changed the sense of a test. That should work, right?