Conditional compiles or dead code removal?

Nick Mueller

Hi!

Pushing my current project from one corner into the other (within my head), I would like to have conditional compiles.
You know the C-style with #ifdef etc.
SPIN doesn't have that, so one workaround would be to relay on dead-code removal. Does SPIN do that? Albeit dead-code-removal wouldn't be the final solution, because it can't handle things like

OBJ
#ifdef VGA
  Video : "VGA.spin"
#else
  Video : "TV.spin"
#endif

or:

CON
#ifdef VGA
  xPos1 = 333
#else
  xPos1 = 444
#endif

Is there some hope for a set of #ifdef-alikes?

Thanks,
Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

Mike Green

Alas, Spin doesn't do dead-code removal. There's just no straightforward way to do what you would like. It's really a pain. The IDE isn't set up for using external pre-processors which could do this for you and it doesn't do any kind of conditional compilation. The best I've been able to do in the Propeller OS is to modify the TV driver so that the VGA and TV drivers use the same display buffer structure (with different sizes), have a common Spin interface for both displays, and load one of two assembly routines based on a declared constant. The work areas for the display driver, keyboard driver, and I2C EEPROM loader are all allocated in the high end of memory and the loader can load a new Spin program into the low end of memory which no longer needs the space for the assembly drivers. Here's the most recent thread: http://forums.parallax.com/showthread.php?p=608678

mike101video

An "include" directive would be nice as well - allow a set of constants to be defined once and then used in multiple applications and objects.

(EXAMPLE: I have a set of command codes that are sent from one Prop to another. The command codes come from different hardware interfaces and cross on wire and wireless links. It would be great to define and maintain those in one file and include them where-ever they are needed. Changes would then flow through with a re-compile.)

Just a though.

Are there any plans for enhancements to the Prop IDE?

Mike Green

These sentiments have been expressed before. The notion of either some kind of conditional compilation or an include directive or both has been brought up before. They are probably difficult to do with the current Propeller Tool and Parallax doesn't have the resources to devote to it. There have been enhancements to the Propeller Tool from time to time, but they are generally bug fixes or small changes that are easily accomplished.

Paul Baker

mike101video said...

Are there any plans for enhancements to the Prop IDE?

Yes, Jeff is busy creating a pretty big enhancement to the IDE.

Most of these requests would fall under the canopy of the compiler which was written by Chip. And he is quite busy designing the new chip.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Mike Green

Paul,
As you can well imagine, this issue will resurface over and over again until:

1) Parallax officially documents the Spin "object code" so some 3rd party can produce a compiler/IDE with additional features ... or
2) The compiler is released as separate module much as the tokenizer was for PBasic so a 3rd party IDE can be built ... or
3) The compiler is extended to support some kind of "pre-processing", either a built-in macro/conditional/include processor or an external one

The proposed C compiler from ImageCraft will relieve some of the pressure for this, but won't solve it because of the lack of Spin support.

The issue is that there are some organizational needs in the large / complex systems for the Propeller that are increasingly being attempted by customers that the current Spin compiler/IDE can't provide. In particular, there is the inability to straightforwardly provide for different hardware configurations and there are fundamental limitations in the object structure supported by the Spin compiler that make what would be straightforward object abstraction very difficult at best. Some of this is fixable with what seem to be simple changes (like an INCLUDE statement and/or an external pre-processor). Some might require changes to the compiler (like allowing objects without VAR space ... just some combination of CON/PRI/PUB/DAT).
Mike

rokicki

Or instead of making VAR illegal, just add a VARSINGLETON or some such, saying that
this VAR is shared by all copies of the object (and thus only a single such object is
automatically shared across); or, another way of looking at it, this VAR section is just a
VARish way of declaring DAT.

This would give us the singleton objects we need, with no changes to the semantics we
have come to expect (except you have to change VAR to VARSINGLETON or some
such) and we are done.

There are cases this won't solve (for instance, you want a FullDuplexSerial for debug
but you also want an array of 10 FullDuplexSerials for other things; here we want one
big singleton FullDuplexSerial for the debugging, that is a Singleton, and then 10
non-singleton FDS for other purposes. But this is easily handled by simply using a
separate SingletonFullDuplexSerial.)

Paul Baker

Mike Green said...
Paul,
As you can well imagine, this issue will resurface over and over again until:
...

Oh I know, when I was writing the Logic analyser which supports either VGA or TV I sorely wished for conditional compilation. Fortunately I had enough memory to do a straight up "if SOME_CONSTANT ..." explicit coding, but even then the OBJ inclusion had to be explicitly modified.

Unfortunatly it always comes down to management of resources and Chip's time is one of the most precious resources·of the company.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

simonl

Maybe Parallax could commision David Barker at mechanique (http://www.mecanique.co.uk/products/compiler/proton-dev-suite.html) to convert the Proton IDE? Sure we'd have to pay for it - I'd be up for that if it's reasonable amount - but if it speeds-up the new functions we're looking for I think it's worth it.

BTW: The Proton IDE allows people to write their own plugins, and that's proven really useful...

Bets thing Jeff could do is make the compiler stand-alone, so it can be called from other app's / IDEs - must be a better way to go long-term?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

BTW: I type as I'm thinking, so please don't take any offense at my writing style

---

www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)

Tom Bampton

See this post: http://forums.parallax.com/showthread.php?p=645706. I've also been pondering a DLL / Framework / Shared Library version of it for IDE integration later down the line. We're not likely to do anything IDE related ourselves, though.

T.