Best Spin tool with conditional compilation?

rokicki

As you may have seen, lonesock and I will be collaborating on the next release of fsrw.

One feature we need is conditional compilation. Is there an existing tool out there that
is Parallax-tool compatible and supports conditional compilation? It need not be an IDE.
Ideally the tool should also make it possible to emit source without the conditionals so that
we can generate different release archives with various features from the same source base.

Also, BradC, is the source for bst available? We'd really like to spend our time on fsrw and
not on tools, but the current Parallax IDE won't get us where we want to go.

Ale

AFAIK only homespun and bst/bstc can compile with conditionals but their source code is not available.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

rokicki

Okay, this may be a stupid question but where is the conditional compilation feature of bst
documented?

Source not available is not a showstopper, except that if there is a bug that we can't work
around, we're stuck.

The ability to generate proptool-compatible source is probably not a big deal; a Perl script
could almost certainly do that without much effort.

I'm curious why BradC isn't releasing source (this is not a complaint in any way, mind you).
I just feel better about using third party code if there is source to examine.

heater

You probably want to use a recent version of BST. I use 0.18-pre8 on Linux with no problems.
You can put #define in your source or set defines in Project->Project options->defines.
You need to enable non-parallax compatible extensions in the project options.

Then you can use #ifdef, #ifndef, #else, #endif in your code.

Cluso and I have been jointly working on the ZiCog emulator using this quite successfully.

Edit: You can't #define values of things in BST (as far as I know) but I think you you can in HomeSpun.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Post Edited (heater) : 6/17/2009 7:36:56 PM GMT

rokicki

Thanks for the advice! This is what I wanted to hear.

I'm confused by "You can't #define values of things in BST
(as far as I know) but I think you you can in HomeSpun."
Can you elaborate on this?

Ale

works:

#define A_NEW_FEINE

#ifdef A_NEW_DEF
  nop
#endif

does not work, you cannot create constants or macros with #define as in C

#define MY_CONSTANT 500

  mov OUTA, #MY_CONSTANT

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL
OMU for the pPropQL/020 propeller.wikispaces.com/OMU

heater

Well you can't do the C things like:

#define array_size 100

only simple defines:

#define USE_EXT_RAM

I think HomeSpun supports the former, I have never tried.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

mpark

Homespun does support simple text-substitution macros, at least in theory. I don't think anyone's ever used them.

It is documented though: propeller.wikispaces.com/Homespun+Spin+Compiler

Good luck with the new fsrw!

BradC

rokicki said...

I'm curious why BradC isn't releasing source (this is not a complaint in any way, mind you).
I just feel better about using third party code if there is source to examine.

I can understand your viewpoint. I like the source to be available to generally.

There are a number of reasons why I have not released the source.

Firstly I've never written a compiler before and therefore my code architecture is so ugly as to be highly embarrassing. The code in bst is not a lot prettier and has numerous nasty hacks and ifdefs to tweak the IDE on three different widgetsets.

Secondly, the build system for bst to compile it for all three platforms is quite complex (including patches to Lazarus and the fpc RTL) and I really don't have the time to support third parties building the code at the moment. Unfortunately its not a case of ./configure && make

Thirdly, I'm just not ready to do it yet. I've always said when I get tired of developing / maintaining the code I'll likely GPL it but for now that's a ways off.

As for the documentation for the #defines :
You need to enable Non-Parallax compatible extensions (Compiler options checkbox in bst and -Ox in bstc)
You have #define, #undef, #ifdef, #ifndef, #elseifdef, #elseifndef, #else, #endif, #warn, #error, #info (on my internal builds I also have #crash - but it's not much fun to use!)

All defines must start in column 0. Defines may not contain spaces (the text after #warn/#info/#error may contain spaces)
Defines are global across the project. They carry forward from the point they are defined. They may be #undef'd at any time.
Defines may be specified on the command line for bstc -Dflibbleisdefined. Defines may be specified in the project file in bst. (Specify defines without the # in the IDE project optinos box)

Unlike Homespun, defines do not allow variable substitution in bst.

I've thought about an option to spit out pre-processed spin files but I've not looked at it hard as currently the tokeniser handles the conditional processing and is not quite geared up to perform as a full blown pre-processor.

With regard to Parallax compatibility, I've spent stupid amounts of hours tweaking the code generation to ensure that generated binaries are bit for bit compatible with the Propeller Tool output.

I currently have 2 cases of difference. One is a 1LSB error in a particular floating point construct involving ROUND() in RB_Hydris_012.spin. The other is an instance where the Propeller Tool folds constants in the last line of (Ch3-Ex12)-RealNumbers.spin (again using floating point constructs). Otherwise, my test harness includes every file in the OBEX, on the Hydra CD, supplied with the Propeller Tool, my own code, code people have sent me that has triggered bugs, and lots of stuff I've downloaded from the forums over time (currently 1694 files). Every file is compiled individually and binary compared against the output of Propellent under WINE for the same file/library code on all 4 platforms (endianess bugs are swines to track down sometimes).

If you write code that does not match the binary output of the Parallax tools, I want to know about it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!

Cluso99

As far as I am concerned, now I cannot live without #DEFINE. Both Homespun and bst support this. So, goodbye PropTool.

However, there is a slight difference in implementation. In homespun, it is only active for the current module (file) whereas in bst it is active in all child modules.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

BradC

Cluso99 said...
However, there is a slight difference in implementation. In homespun, it is only active for the current module (file) whereas in bst it is active in all child modules.

I was kinda torn when I did this, but the reality is that most compilers do it this way and I find it useful not to have to place a define in every project file.

I also thought about global (-Ddefine) and local (to the source file) but it started to get inconsistent and messy.

I tend to use them for either platform or debug features (-Dprotoboard / -Ddemoboard / -DDebug) and in those contexts having them global tends to work nicely.
I also use #warn and #error quite a bit as a quick poke in the eye to remind me of what I'm actually doing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!

Cluso99

I actually find it useful to be global too and #warn #error are great additions too.

Heater and I are using #define for different hardware configurations in ZiCog.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

rokicki

Great, thanks for the feedback! BradC, your tool is great, and I appreciate it very much.

Releasing source is totally your decision, of course, but I encourage you to reconsider.
Simply say "source is released with absolutely no support for building". Even with
unbuildable source, you'd be amazed at the bugs people can find and fix for you. And
if you disappear for whatever reason (lack of interest, medical issue, etc.) then the
code still lives.

You can't be embarrassed by the code; you spent a lot of time on it, and everyone
understands this is a hobby project and it's amazing it works at all. And I'm sure a lot
of us want to know how you did it, so we can learn from it.

Another advantage of releasing source is people can integrate it into other tools.
Can you imagine an integrated viewport/bst/gear that allows you to do everything from
one tool? With a debugger that lets you find out exactly when and where a particular
variable was smashed? Etc.? Even if they can't build it, they may be able to build
the subset they need.

Anyway, just my two cents.