Spin compiler

stevenmess2004 · 2008-02-26 09:48

It looks like several people want to do this so I thought I would start a thread for it instead of taking other peoples threads off topic.

I'm happy to help but my experience in this is zero so someone else will have to take over

Personally I would like to see something that can be run on the propeller as then we won't have to worry about operating systems differences and all the associated problems. As a suggestion rokicki said that the code for fsrw was written in C and that he had a converter for translating it to spin. If he agrees, this may be a good thing to use as then we can have compilers to run on pcs and the prop.

So, over to more experienced people

And if my suggestions above are no good than just ignore them

Robot Freak · 2008-02-26 10:41

I would definitely like to see a command-line compiler for SPIN.
But the question is, will Parallax make it available?
If not, there are two options:
- translate a language (C, Basic, Forth, whatever) into SPIN byte codes
- translate the existing SPIN language into SPIN byte codes

The last one isn't a good idea, because the compiler will never get the same as the Parallax compiler.
People will always have to learn the differences.

stevenmess2004 · 2008-02-26 10:52

I think that there are two reasons for wanting our own compiler.
1. PropTool does not support a preprocessor. A preprocessor would be really useful for setting up software for different board/pin/crystal setups. It would also make DOL and other things like it much easier to use.

2. It would be able to run on something other than Windows. I personally use a Mac. I know that there are several others that use Macs and I think that there are a couple that use Linux.

Robot Freak said...
- translate a language (C, Basic, Forth, whatever) into SPIN byte codes

If you are going to translate another language than you may as well go to using your own VM like CodeVision is doing with their C compiler.

said...
- translate the existing SPIN language into SPIN byte codes

The last one isn't a good idea, because the compiler will never get the same as the Parallax compiler.
People will always have to learn the differences.

I don't think that there would be too many differences except for some added things like preprocessor calls. The advantage would be that all the objects already made should work.

Robot Freak · 2008-02-26 11:05

stevenmess2004 said...
The advantage would be that all the objects already made should work.

That's true, but then we are not only talking about a SPIN compiler.
Most objects are using ASM.

stevenmess2004 · 2008-02-26 11:09

But ASM is easy

I've even done a program that does basic assembly on the prop using a keyboard and TV. If you were going to do a SPIN compiler you would have to do an assembler as well.

hippy · 2008-02-26 13:28

A Spin compiler should be doable. Looking at how the compiler should work, my observations are -

1) Find the deepest objects and compile those first, then next less deep etc

2) All objects create a relocatable image plus 'exported' constants and PUB names and function signature.

3) Compilation of an object is at least three pass. First finding sub-objects, second finding constants and methods locally and in sub-objects ( the exports of 2 above ), third is bytecode generation, fourth is fixing up target address and branch distances. Handling forward branches so the branch uses minimum bytes can get tricky in this.

4) Once the top-most object has compiled that is put into a wrapper which gives the final .eeprom image. All objects are chained together. Additional address fixups could occur here; objects that are the same are only included once.

So really it's a compiler and linker rolled into one. My vision of what we should have for our compilation process is -

1) A pre-processor which creates processed .spin files which will then be compiled.

2) Each object is compiled to generate its bytecode and export list, produced as a textual bytecode 'assembler-like' source.

3) An optimiser which takes that bytecode source, produces an optimised version. This is an optional step which can simply copy input to output to start with.

4) A linker which takes all optimised bytecode assembler sources and create a single bytecode source.

5) A bytecode assembler which takes the bytecode source and creates the binary image.

As can be seen, my preference is for all intermediate files to be in a human readable form. That aids debugging and makes it easier for people to insert their own tools into the tool chain. Being readable it should also make what people see more obvious with less documentation necessary.

An interesting, and complex, question arises about how we pre-process the files. Do we do this linearly, or do it in the same 'deepest first' way as the Parallax compiler does it ? That has an impact on how we handle the same object used multiple times. Linearly and each use of the object could generate different post-processed code if the conditionals have changed during processing, done 'deepest first' there would only be one object using the conditionals active at the time it is compiled. If different, every object has to be re-compiled, if not then only one compilation of that object has to take place. This opens up the issue of whether pre-processing is a separate step, or an integral step of the compilation itself.

Should pre-processing simply create one big spin file with everything in it which we then compile and leave it to an optimisation step to compact whatever turns out to be common objects ? Do we simply restrict ourselves to global #defines only which must be set before compilation begins - that simplifies things greatly. Do we allow local #defines but restrict #ifdef to only referencing global #defines - that's more useful.

I haven't got my head round this issue yet and suspect it's one of the reasons that Spin doesn't support conditional compilation. It's not that it cannot, but how to. Because I find it hard to put the problem into words; here's an example -

MyProgram.spin

OBJ
  tv       : "Tv_Text.spin"
  #define MY_TEXT "First"
  #define USE_TAB true
  first    : "MyObj.spin"
  #define MY_TEXT "Second"
  #undef  USE_TAB
  second   : "MyObj.spin"
PUB Main
  tv.Start(12)
  tv.Out( first.GetTab )
  tv.Str( first.TextPtr )
  tv.Out( second.GetTab )
  tv.Str( second.TextPtr )

MyObj.spin

#ifdef USE_TAB
CON
  TAB = $09
PUB GetTab
  return TAB
#endif
PUB TextPtr
  #ifdef USE_TAB
    return String( TAB, MY_TEXT, $0D, $0A )
  #else
    return String( MY_TEXT, $0D, $0A )
  #endif

CardboardGuru · 2008-02-26 16:19

I think the problem is trying to shoehorn a C preprocessor into SPIN.·It's problematic enough with C with people using #defines where they should have used consts, and a huge variety of gotchas particularly to do with macro substitution.··

hippy said...

OBJ
  #define MY_TEXT "First"
  #define USE_TAB true
  first    : "MyObj.spin"
  #define MY_TEXT "Second"
  #undef  USE_TAB
  second   : "MyObj.spin"

Obviously that's a no-no as the defacto standard for Spin is for MyObj.spin only the be comiled once and linked in.· So the answer is to not allow conditional compilation based on a constant in a higher level object.· And don't allow redefinition.· Luckily this is what ordinary SPIN consts will give you anyway.· If you do conditional compilation based on them, then it's based on whats in the current object itself, or what's in a lower object.· Your problem is then illegal.

In a nutshell:

Don't have #DEFINE
Do have #IF SPIN_CONSTANT == VALUE...#ELSEIF...#ELSE...#ENDIF

Actually,·one might not want to·use # as the preprocessor escape either, as that will·give·ambiguity·within CON blocks, where a line starting with # is legal SPIN.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

dfletch · 2008-02-26 17:54

Thanks for making a new thread, I'm one of the guilty ones hijacking the other thread

Just a thought - if we must have macros (I'm not a huge fan but I can see that they are useful sometimes), perhaps we can protect them by putting them inside comments so that the PropTool doesn't choke on it?

Cheers,

--fletch

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto

rokicki · 2008-02-26 17:56

I'm not sure I'd go with the C->spin route for a Spin compiler. The way you'd write a compiler
like this in C is very different than the way you'd have to write it in Spin.

By the way, I do have a sourceforge project for a command-line Spin compiler set up, if anyone
wants to use that. (It uses the name spinc.)

I would prefer the source language to be either C, C++, or Java. But that's just me.

I've actually started some work, mainly in figuring out the lexer (it's not quite as trivial as you
might think). But I had to put it aside for other things.

dfletch · 2008-02-26 18:03

Ugh, you know what? I have to argue against macros entirely. Introducing those, it's no longer Spin language, but an incompatible extended language. Seems like this will cause confusion and it hardly seems worthwhile for the dubious benefit macros give. My vote is, make this thing as close to 100% compatible with Parallax Spin as possible.

If someone wants macros, why not just use C style macros and run your sources through cpp before the spin compiler?

Cheers,

--fletch

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto

rokicki · 2008-02-26 18:06

I think the only reasonable thing to do, up front, is to make a 100% compatible spin compiler, and test the heck out of it against the
Windows IDE-based one. Only after that's working would I even *consider* adding extensions.

Any source that uses extensions is not compatible with the Windows compiler, meaning you make that code useless for the majority
of people who are using the Windows compiler. Yuck. One of the great things about Spin is everyone can use objects written by
anyone else.

And in response to

> The last one isn't a good idea, because the compiler will never get the same as the Parallax compiler.

I think it wouldn't be *that* hard to make it exactly 100% compatible with the Propeller IDE compiler. The Prop IDE compiler is
not that complicated a beast.

Any command-line Spin compiler that doesn't have a 100% compatibility option is something I'm really not that interested in.
(And I believe that option should be the default.)

Post Edited (rokicki) : 2/26/2008 6:11:08 PM GMT

OwenS · 2008-02-26 18:20

On the preprocessor front, it shouldn't be hard to add a -p switch, which causes it to invoke your platform's CPP. On *nix this wouldn't be hard, certainly, and it's definitely possible on Windows. For Windows, it would probably be wise to ship MingW's CPP with the distribution, because
a) Thats redistributable
b) It will match the GCC CPP used on *nic
c) It takes the common argument format, -Dblah_blah[noparse][[/noparse]=val]

Phil Pilgrim (PhiPi) · 2008-02-26 18:51

The scoping rules for constants (both run-time and compile-time) need to be reexamined in full. As it currently stands, all of an object's CONstants are exported by default, but none of it's DAT variables are. This needs to change. It should be possible to declare within an object which of its constants and variables get exported, as is done with methods using the PUB and PRI declarations. I would also add a DEF section, which would be used to define compile-time variables, which could also be declared exportable or not.

As to a syntax for accessing external symbols (run-time and compile-time), there are three ways to do this, and all three should be part of the language:

1. The current method:

····ObjName#Symbol.

2. Global importation in the OBJ section:

····pr : "TV_WText" (CR, LF, CRSRLN) to import specific symbols.
····pr : "TV_WText" !(CR, LF) to import all exported symbols, except those that are named.
····pr : "TV_WText" !() to import all exported symbols.
····pr : "TV_WText" or pr : "TV_WText" () to import no exported symbols.

Symbols imported this way would not require further qualification using the # notation. However, symbols not globally imported could still be imported explicitly with the # notation. Naming conflicts between two objects would generate an error.

3. Local importation via a use block:

····use pr (CR, LF) for specific symbols.
····use pr !(CR) for all exported symbols except the ones named.
····use pr !() for all exported symbols.

Again, the # would not be required while in the block. Naming conflicts here would be resolved by giving priority to the innermost use block.
_________________

As to preprocessing, I would add a PRE section, which would define a batch file or shell script that invokes a preprocessor to be used with the object. After all, not all objects will use the same preprocessor, and not all preprocessors need be written with the same parameter-passing methods. (See my recommended usage in the PDF I posted here.)

-Phil

VIRAND · 2008-02-26 19:48

Phil Pilgrim (PhiPi) said...
As it currently stands, all of an object's CONstants are exported by default, but none of it's DAT variables are.

It looks to me as if constants require no memory because they are just labels, but this may change if the editor is on
the Propeller... In other words the constants are just labels for numbers that you might not want to remember every
time you use them in the code, but rather use names that describe what they're for to make the code readable.

With an on-Prop editor, the source code must retain the CONstants only until final compilation, (it seems to me).
It also seems to me that the DAT block exists in HUB RAM, and at least the main object is easily capable of accessing it.

Damien Allen · 2008-02-26 19:50

I agree with rokicki, build a 100% compatible version first, then add extensions or optimisations that might be able to be derived from the spin interpreter source

hippy · 2008-02-26 20:11

dfletch said...
Ugh, you know what? I have to argue against macros entirely. Introducing those, it's no longer Spin language, but an incompatible extended language. Seems like this will cause confusion and it hardly seems worthwhile for the dubious benefit macros give. My vote is, make this thing as close to 100% compatible with Parallax Spin as possible.

The thing which needs to be decided is - why are we doing this and what is the goal ?

On one hand it's to provide a Spin programming environment to those who won't or can't use the Windows XP PropTool, on the other it's to overcome the limitations of what there is with the PropTool compiler.

Get a fully compatible compiler running first ( and always keep a 'Pure Spin Only' option ), but should we hold back on enhancements which Spin and the Propeller would benefit from even when it breaks compatibility ? One case in point is function pointers and call-backs which would be feasible to implement in a third-party compiler.

For me it's far more important to overcome the limitations of Spin which currently make things very difficult or inefficient than provide tools for other platforms ( and I'm in the "I don't want to run XP" camp ).

I'd take exception to macros of being of dubious benefit with Spin. For supporting Prop I and Prop II efficiently and for maintaining single source ( particularly objects ) which can be used in a variety of different configurations without huge runtime overheads of not needed code I believe they are essential.

CardboardGuru said...
So the answer is to not allow conditional compilation based on a constant in a higher level object. And don't allow redefinition. Luckily this is what ordinary SPIN consts will give you anyway.

Although, for example, a TV object which can be NTSC or PAL through conditional compilation, would want its conditional compilation based upon something higher up in the program ( ie, main application ).

Another example is code which would be optimised for either Prop I or Prop II using conditional compilation.

At present, Spin constants only get exported upwards (obj#const ), anything passed downwards has to go via a method call.

CardboardGuru said...
Actually, one might not want to use # as the preprocessor escape either, as that will give ambiguity within CON blocks, where a line starting with # is legal SPIN.

Well spotted. $IF, $ELSE, $ENDIF etc would be reasonable alternatives and shouldn't conflict with anything. Hex numbers would never start a line.

hippy · 2008-02-26 20:24

@ dfletch : Re Lemon/RE2C, Bison/Flex in the other thread ...

I'd say do it however you want, test it as a pure syntax checker against real source and see what falls-over, fix it, and then at the end of the day decide how to move on, what needs tidying up and whether to start again with better knowledge, different tools etc.

There's bound to be something we all miss anyway, and there's always a few false-starts, back-trackings and rip-ups as we get to grips with what needs doing and how best to do it.

Damien Allen · 2008-02-26 20:30

If this does go ahead, what would be the possibility of the person implementing it, create a sort of design diary so people who are interested in its creation and the creation of such software in general would be able to see how it's done.

simonl · 2008-02-26 22:16

hippy said...
The thing which needs to be decided is - why are we doing this and what is the goal ?

What a refreshing change that is; if only I had a quid for every time I've had to say that where I work :SIGH:

My tuppence worth:

1. Multi-platform - because that's probably the most requested missing peice

2. Conditional / pre-compilation

3. Includes (although, as I typed that, I started to think 'OBJ'...)

4. Macros

5. Modularity / IDE plug-ins - so anyone can hook-up their own processor at any junction in the process, or anyone could provide for extra functionality in the IDE, like an in-circuit-debugger...

Not sure if all of those belong in the list, but I'm sure someone will correct me!

{edit}
For an example of plug-ins, take a look at what's been done for the Proton Development Suite IDE at: www.protongeeks.com/index.php?option=com_content&task=section&id=9&Itemid=30

They've also got a library manager for it at: www.protongeeks.com/index.php?option=com_content&task=section&id=12&Itemid=44
{/edit}

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

Simon

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 ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style

Post Edited (simonl) : 2/26/2008 10:34:34 PM GMT

CardboardGuru · 2008-02-26 22:44

hippy said...

Although, for example, a TV object which can be NTSC or PAL through conditional compilation, would want its conditional compilation based upon something higher up in the program ( ie, main application ).

Not necessarily.· Just have a globals.spin file which you refer to in every object that needs·one of the constants.· That makes it a lower level object accesible with the OBJ#CON syntax.·

I really do think it's asking for trouble having two different systems of constants, even more than for C.· There's no need to follow C·with an accident of history.

As to macros, I agree with those that say it's not needed.· The major point of doing a preprocessor·is for compile time configuration.· So that the same source can be compiled for different development or production boards or i/o pin usage by just changing a constant or two.· #IF...#ELSEIF...#ELSE...#ENDIF does that.

I agree with the person that suggested putting the preprocessor lines in comments so that the source remains compilable with the Parallax Spin compiler.· (Eric Moyer's and Ariba's existing precompilers work like that.)· Better yet would be if it compiled correctly for a default configuration when in the Parallax compiler.· This is possible.· Here's a snippet of code that should appear in nearly every program that would benefit from conditional compilation:

CON
'uncomment the block which suites your system.
'Hybrid Defines
        _CLKMODE                = xtal1 + pll16x
        _XINFREQ                = 6_000_000 + 0000
' Hydra Defines
'       _CLKMODE                = xtal1 + pll8x
'       _XINFREQ                = 10_000_000 + 0000
' Proto/Demoboard Defines
'        _CLKMODE                = xtal1 + pll16x
'        _XINFREQ                = 5_000_000 + 0000

Instead do this as:

CON
HYBRID = 0
HYDRA = 1
PROTO = 2
BOARD = HYBRID

'#IF BOARD == HYBRID
        _CLKMODE                = xtal1 + pll16x
        _XINFREQ                = 6_000_000 + 0000
'#ELSEIF BOARD == HYDRA
'#      _CLKMODE                = xtal1 + pll8x
'#      _XINFREQ                = 10_000_000 + 0000
'#ELSEIF BOARD == PROTO
'#      _CLKMODE                = xtal1 + pll16x
'#      _XINFREQ                = 5_000_000 + 0000
'#ENDIF

The trick here being for the preprocessor to realise that '# is not a comment, whilst the parallax compiler will consider it to be so.· The Parallax compiler will always compile correctly for the Hybrid, unless you manually change the comments.· The new compiler would compile the appropriate section based on the BOARD constant.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

Post Edited (CardboardGuru) : 2/26/2008 10:52:23 PM GMT

dfletch · 2008-02-26 23:21

I just did a bit of testing with cpp. I was wondering if it treated # as a special character or if e.g. "#ifdef" is a whole token. It appears to get treated as a special character, and the following test fails:

CON

  #a, b, c, d, e
  
#define TEST
  
#ifdef TEST
//  test is defined
#elif !TEST
// test is not defined
#endif

$ cpp test.spin

Unfortunately, this errors out with "invalid preprocessing directive #a".

So yes, a custom preprocessor would be essential.

I'm tending to agree with the folks who say "target a 100% compatible Spin compiler for now, add extensions later". The default operation should be a compatible compiler, with command line switches to turn on the exotic features.

Cheers,

--fletch

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Join us in the Un-Official Propeller IRC channel: irc.freenode.net #propeller
Newbies, oldies, programmers, math professors, and everyone in-between welcome!
Propeller IRC howto

Phil Pilgrim (PhiPi) · 2008-02-27 00:59

I frankly can't see any reason to put macros or any other preprocessor code inside comments. The Spin compiler will never see unpreprocessed code, anyway, so there's no point in trying to "protect" it. A good preprocessor will either delete the uncompilable lines or do the comment embedding itself. There is only one thing to agree on regarding the preprocessor, and that's how to specify its invocation. This, I believe, is best kept as open and flexible as possible, via (as an example) a PRE section in each Spin file that tells how it's to be preprocessed. From there, it's up to each individual who chooses to write a preprocessor to determine the correct source code syntax for his needs.

As a consequence, I also cannot see why macros and conditional compilation need to be discussed as special cases. If a person wants these features, he can write a preprocessor to provide them. There's no reason to agree further on how — or even whether — they're to be handled. The problem with any "standard" syntax is that it freezes out unanticipated features from future consideration. With generalized preprocessor hoodks, this kind of standardization is entirely unnecessary.

-Phil

CardboardGuru · 2008-02-27 01:07

Phil Pilgrim (PhiPi) said...
I frankly can't see any reason to put macros or any other preprocessor code inside comments. The Spin compiler will never see unpreprocessed code, anyway, so there's no point in trying to "protect" it.

The reason is because the whole point of this is to only release one variant of a program or object.·If I write a graphics driver, I want people that are using Parallax's compiler to be able use it as well as someone using the proposed new compiler with conditional compilation facilities.

The person using Parallax's compiler will have to configure for their particular board by tweaking and commenting out sections, as now.· The person using the new compiler will just have to configure by setting up a constant or two.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

Post Edited (CardboardGuru) : 2/27/2008 1:15:53 AM GMT

Phil Pilgrim (PhiPi) · 2008-02-27 01:32

CarboardGuru.

I guess I'm more willing than you are to accept any new compiler as a fork in the road. But even without that, why not leave the syntax of things like macros and conditional compilation up to whoever writes his own preprocessor? If that person wants to require that the directives be embedded in comments for compatibility with Parallax's compiler, he can. But that requirement should be a feature of the particular preprocessor being used, not of the compiler itself. Besides, the whole idea behind a preprocessor is to produce base-level compatible code, not to require it.

-Phil

deSilva · 2008-02-27 01:33

I just see... I like this even better:

CON 
 BOARD = HYBRID 

 HYBRID = 0  
 HYDRA = 1 
 PROTO = 2 

  _HYDRASET  = NOT (HYDRA-BOARD)
  _HYBRIDSET = NOT (HYBRID-BOARD)
  _PROTOSET  = NOT (PROTO-BOARD)

    _CLKMODE     = xtal1 + ( pll16x & (_HYBRIDSET | _PROTOSET) | pll8x & _HYDRASET )
    _XINFREQ      = (6 & _HYBRIDSET | 10 & _HYDRASET | 5 & _PROTOSET) * 1_000_000

deSilva · 2008-02-27 01:38

Hmm... one of my postings has disappeared ... funny..

What I said there is that you can substitute many "variants" by formula as above. HOwever this is limited to parametrization as the SPIN compiler does not optimize unused code, which is a pity.....

CardboardGuru · 2008-02-27 01:56

Phil,
You might be all too willing to take on a new compiler, and leave the Parallax compiler behind, but if you are producing programs or objects that you want others to be able to use, then you have to make allowances for the other people who won't make that move. The likelyhood is that the majority of people will stick with the parallax compiler as the official compiler. After all it's a minority Propeller users who even follow these forums.

As to your idea for creating a facility for multiple different preprocessors, I don't buy it. Choice is not always a good thing - sometimes it leads to confusion and unnecessary duplication of effort. Better to thrash out a good standard than to have everyone doing their own thing in my view.·If the huge community of C programmers manage to use a single specification for a preprocessor, why would the tiny community of Spin programmers need multiple incompatible preprocessors.·

Sure sometimes there is a need for specialist preprocessors, such as LEX/YACC.· But since the general idea behind the new compiler seems to be a series of command line tools for different phases, other·preprocessors can be applied anyway in those special cases, just as they are with C.

I can see why you like the PRE section idea, because it's what you used in CONTACT.· But what you've done there is horrendously non-portable, which was fine for a Parallax Windows IDE add on, but goes against another of the main objectives of a new compiler.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

Post Edited (CardboardGuru) : 2/27/2008 2:17:37 AM GMT

hippy · 2008-02-27 03:17

Perhaps the approach to pre-processing / macros is not what we could have but what we need ?

In that respect, local scope substitution macros and application global flags for use in conditional compilation would IMO suit the great majority of cases. If the PropTool ever supports the same, global flags can be set as defaults in the PropTool; which board, what crystal, Prop I/II, PAL/NTSC. If most source code compiles then runs correctly without any edit at all regardless of end-user setup that's the ideal goal IMO for conditional compilation.

Having global flags only also circumvents any issues as to how objects need to be processed. KISS. Which has the advantage that the PropTool may more likely adopt the same later.

Also, from what people don't like we may perhaps arrive at what is acceptable ...

@ CardboardGuru : I don't like the idea of commented directives; to me they are commented-out directives.

@ Phil : I'm not that keen on too much divergence. A single agreed mechanism of pre-processing / conditional compilation would IMO be preferable. Accepting that people are free to go off on their own as needs dictate.

@ deSilva : Although that means of selecting XTAL etc works, it's very cumbersome, and error prone, especially if more platforms get added, or someone wishes to define their own.

Added : The need for macros. Most people can live without them, but anyone who has tried to construct any serious LMM using PASM will soon find how essential they are.

Post Edited (hippy) : 2/27/2008 3:24:34 AM GMT

Phil Pilgrim (PhiPi) · 2008-02-27 03:50

Standards are fine, as long as they're optional. I'd much rather adhere to a standard that's been forged and proven in a free marketplace than one that's been established by committee. I admit to being an iconoclast; but it's an acquired trait, tempered by the shortcomings of too many poorly-contrived "standards" to which I've been forced to conform.

Besides, the output of any preprocessor has to be base level language-compliant anyway. If someone wants their own odd piece of code to be used universally, they can just as easily provide the preprocessed version as the original source.

When it comes to preprocessors, it's important to set one's sights well beyond macros, conditional compilation, and other such simple text-substitution facilities. A preprocessor can be used to provide array constructors, for example, a better dereferencing syntax, LMM assembly instructions, or even a PBASIC-like DEBUG statement, to name just a few. As a testbed for new base language features, an open, universal preprocessor facility can't be beat. But such a facility would be crippled irreparably by any well-meaining, but short-minded attempts to constrain its use to certain tasks or to use a certain syntax.

If a committee wants to convene to recommend a particular preprocessor for the sake of portability, that's fine. But don't make that preprocessor the only one the compiler can make use of! The only base-level standards that ought to be defined by the compiler/IDE itself are how to invoke the preprocessor of one's choice, on a file-by-file basis, and how that preprocessor formats error information for reporting to, and highlighting in, the IDE.

-Phil

Post Edited (Phil Pilgrim (PhiPi)) : 2/27/2008 5:47:54 AM GMT

stevenmess2004 · 2008-02-27 06:22

By the sounds of this everyone wants something different

To try and sum up everything

There are two reasons for own compiler
1. To run on an os other than Windows or unsupported versions of windows
2. To add new features to SPIN

Number 2 seems to be causing the most trouble. I think that the best thing to do would be to first focus on making something that is 100% compatible with the Parallax compiler (i.e. will compile the same code and it will run in the same way). While doing this we should ensure that it is easy to go back and allow the adding of extra passes/pre-processing anywhere in the chain. This will allow us to add pre-processors, optimisers and whatever else we want at a later stage.

I think that we also need to consider some other things such as
1. Who is the target group? Do we need to make plugins for IDEs or are people happy with command line tools?
2. Should we make each pass a separate program or make everything into one big program? I think that the first option will be better.
3. Should we consider making it possible to use braces instead of spaces and things like that? This shouldn't too hard if we think about it now and design the compiler for it. But I don't think that we really want to change the spin syntax. It may however allow C programs to be ported easily though.
4. I know that people are interested in other languages like basic and forth etc. Is it easily possible to do something like what they use in GCC to easily support other languages?

Phil Pilgrim (PhiPi) · 2008-02-27 07:01

That's a good summary. I think the base-level language needs to be compatible with Parallax Spin and produce the same bytecode output for verification — at least initially, until all the bugs are eradicated. Op systems portability (Windows, Linux, native OS/X or OS/X:X11) is the more overriding concern, to start with, than the addition of new features. Things like braces can be accommodated by a preprocessor, anyway, for those who think them necessary.

(But I will defend to the death one's right to have them!)

Optimizers are another matter, though. Constant-folding, for example, is easier to do during compilation, since operations can easily be performed, instead of being emitted, as the expression stack is processed. Doing it before compilation in a preprocessor is possible, but it requires parsing the expressions the same as the compiler would, which would be redundant. Doing it after compilation on Spin bytecodes is also possible, but messy, requiring relocation issues to be dealt with.

As to IDEs, incorporation can be accomplished without specific plugins. You just need to provide sufficient output through STDOUT to report either a successful compilation, or error information with enough detail that the error can be flagged and highlighted. The Parallax PBASIC compiler does this, for example, when invoked from the command line with the right switches set.

-Phil

Spin compiler

Comments