oopic-compiler-devel

[Oopic-compiler-devel] Summary

[Neil D. <nd...@us...>]

I went through our longish thread of ideas and question asking and have
come up with a summary of what we discussed, just so we know where we are:

* What level of C language support are we aiming for?
  We all pretty much agreed to implement C as completely as we can within
  the constraints of the OOPic, so aiming for K&R/ANSI where possible but
  foregoing things like floating point support.

* What other languages do we want to support?
  It seems we're all in favour of C as the primary language to support, but
  BASIC seems to be the more popular amongst the community.  So
  implementing both looks like the best bet, with Java syntax as a
  runner-up.

* Do we want a mode that allows "standard" OOPic BASIC/C/JAVA to be compiled?
  I think we all agreed that some kind of preprocessor to do the conversion
  would be the easiest, converting 'legacy' OOPic script syntax to our new
  improved syntax.
 
* What platforms do we want to support?
  General concensus was DOS, Windows, Linux, and maybe Mac.  We should aim
  to use libraries available on all these platforms to try and maintain a
  single codebase for all the platforms.

* What implementation language(s) do we want to use?
  We all agreed on C.

* Should we use a compiler compiler, such as flex/bison/lex/yacc ?
  Looks like we're all in favour of this, as it will save development time
  and make adding/changing the supported syntax easier.

* What extra features do we want to support?
  We came up with:
   Inline functions
   Word / byte / bit arrays in EEPROM via direct references rather than function calls:
   Proper shift operators
   Malloc to work in EEPROM, and providing pointer arithmetic, similar to Andy's lib
   Libraries of useful scripts and VC stuff
  Also need to think about these features:
   Differentiate between VC and interpreted code, like Delphi divisions
   More object-oriented style for user classes (perhaps)

* What bugs in the existing languages do we specifically want to address?
	We tackle every bug we know of

* Do we need structures and unions, for example?
	Would be nice in the long term

* Requested feature list
    We agreed to publish an intended feature list to the forum once we're confident we can
    do stuff, and see what else people want.

* Are we making a collection of command line tools, or are we considering an IDE?
    The general concensus was for command line tools

Neil
-- 
Neil Durant
<nd...@us...>

Re: [Oopic-compiler-devel] Summary

[D. D. M. <dd...@mc...>]

Neil,

A new category:
Is the tool to support all firmware revisions of the OOpic?

A new category:
Testing is going to be done how?  What is the testing methodology, etc?  Do
any of us have a suit of OOpic in the tools supported firmware revisions?
If not, are we going to ask Scott Savage for a few freebies?

A new category:
Installer issues have been recently discussed on the OOpic list.  What
'installer' issues will this project need to address?

Best Regards,
Daniel

PS. For the record, I have one unused OOpicR.


----- Original Message -----
From: "Neil Durant" <nd...@us...>
To: "OOPic Compiler List" <oop...@li...>
Sent: Wednesday, 05 May 2004 09:26
Subject: [Oopic-compiler-devel] Summary


> I went through our longish thread of ideas and question asking and have
> come up with a summary of what we discussed, just so we know where we are:
>
> * What level of C language support are we aiming for?
>   We all pretty much agreed to implement C as completely as we can within
>   the constraints of the OOPic, so aiming for K&R/ANSI where possible but
>   foregoing things like floating point support.
>
> * What other languages do we want to support?
>   It seems we're all in favour of C as the primary language to support,
but
>   BASIC seems to be the more popular amongst the community.  So
>   implementing both looks like the best bet, with Java syntax as a
>   runner-up.
>
> * Do we want a mode that allows "standard" OOPic BASIC/C/JAVA to be
compiled?
>   I think we all agreed that some kind of preprocessor to do the
conversion
>   would be the easiest, converting 'legacy' OOPic script syntax to our new
>   improved syntax.
>
> * What platforms do we want to support?
>   General concensus was DOS, Windows, Linux, and maybe Mac.  We should aim
>   to use libraries available on all these platforms to try and maintain a
>   single codebase for all the platforms.
>
> * What implementation language(s) do we want to use?
>   We all agreed on C.
>
> * Should we use a compiler compiler, such as flex/bison/lex/yacc ?
>   Looks like we're all in favour of this, as it will save development time
>   and make adding/changing the supported syntax easier.
>
> * What extra features do we want to support?
>   We came up with:
>    Inline functions
>    Word / byte / bit arrays in EEPROM via direct references rather than
function calls:
>    Proper shift operators
>    Malloc to work in EEPROM, and providing pointer arithmetic, similar to
Andy's lib
>    Libraries of useful scripts and VC stuff
>   Also need to think about these features:
>    Differentiate between VC and interpreted code, like Delphi divisions
>    More object-oriented style for user classes (perhaps)
>
> * What bugs in the existing languages do we specifically want to address?
> We tackle every bug we know of
>
> * Do we need structures and unions, for example?
> Would be nice in the long term
>
> * Requested feature list
>     We agreed to publish an intended feature list to the forum once we're
confident we can
>     do stuff, and see what else people want.
>
> * Are we making a collection of command line tools, or are we considering
an IDE?
>     The general concensus was for command line tools
>
> Neil
> --
> Neil Durant
> <nd...@us...>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Oopic-compiler-devel mailing list
> Oop...@li...
> https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel
>

Re: [Oopic-compiler-devel] Summary

[Neil D. <nd...@us...>]

Good questions!

D. Daniel McGlothin wrote:
> A new category:
> Is the tool to support all firmware revisions of the OOpic?

I say definitely - aim for the most recent firmware revision, and then we
just disable features that aren't present in lower OOPic versions.  Unless
the compiler has bizarre workarounds for quirks in each OOPic version?

> A new category:
> Testing is going to be done how?  What is the testing methodology, etc?  Do
> any of us have a suit of OOpic in the tools supported firmware revisions?
> If not, are we going to ask Scott Savage for a few freebies?

We can probably test the bulk of our work by simply comparing the generated
op-codes with those from Scott's compiler, using 'equivalent' code.  This
will be especially useful for testing object support, which I guess won't
be changing much from the existing compiler, beyond maybe giving errors
when someone tries to access vapourware.  Plus, I don't think testing
against actual sonars, motors, compasses etc is going to be practical!

However I guess that'll only work so far, and we'll need to do testing
against real hardware for some stuff.  I have an OOPic II+ (b.2.2+) and an
OOPic II (b.1.0).

Perhaps for the various bits of hardware we don't have, we could recruit
a couple of beta testers from the OOPic forum who have the required
itarget hardware.

Same applies for different development systems - for example for the
Windows compiler we're going to have to test on Win95/98/ME/NT/2000/XP.

Of course, as it's open source, I guess it's reasonable to release it
having tested it on the hardware we have, and list the hardware it's been
seen to work on.  Then people can test it on their own hardware and report
back, in the true spirit of open source knowledge sharing!

I think we'll be lucky if Scott gives us some freebies!

> A new category:
> Installer issues have been recently discussed on the OOpic list.  What
> 'installer' issues will this project need to address?

Well, I think the installer issue has come up because of the IDE's
dependency on VB runtime files, which may/may not be present on a given
system, and may not be the correct version.

I'm hoping that our compiler will be pretty self-sufficient, not relying on
installed DLLs or libraries, and so it should be a simple operation of
putting the compiler exe somewhere on the path.  If the compiler depends on
Windows DLLs etc, then we will have lost cross-platform compatibility as
there are no equivalents to the various Windows DLLs on DOS, Linux and
MacOS.  I think considering the target audience, it would be acceptable to
make a static build with any libraries compiled in.

I should be able to "find" a copy of InstallShield for creating a proper
installer for Window.  For DOS, I guess we can get away with a batch file
or similar.  And for Linux I think it would be acceptable to ship it as a
source code .tar.gz file with compilation instructions (this is widely
regarded as reasonable on Linux).  Alternatively it wouldn't be hard to
create ready-compiled RPM or DEB files for Linux.

One question that arises from this - are we intending to allow out compiler
to work as a drop-in replacement for the existing compiler, ie so that it
works from the existing IDE.  If so, then the installer will have to locate
the currently-installed compiler, rename it, and replace it with the new
one.

Neil
-- 
Neil Durant
<nd...@us...>

Re: [Oopic-compiler-devel] Summary

[D. D. M. <dd...@mc...>]

Neil,

> One question that arises from this - are we intending to allow out
compiler
> to work as a drop-in replacement for the existing compiler, ie so that it
> works from the existing IDE.  If so, then the installer will have to
locate
> the currently-installed compiler, rename it, and replace it with the new
> one.

Perhaps, since the IDE is open, we could patch the IDE to allow compiler
selection.  No need really to lock the user into our preferred product.
<smile>

Best Regards,
Daniel



----- Original Message -----
From: "Neil Durant" <nd...@us...>
To: "OOPic Compiler List" <oop...@li...>
Sent: Wednesday, 05 May 2004 19:46
Subject: Re: [Oopic-compiler-devel] Summary


> Good questions!
>
> D. Daniel McGlothin wrote:
> > A new category:
> > Is the tool to support all firmware revisions of the OOpic?
>
> I say definitely - aim for the most recent firmware revision, and then we
> just disable features that aren't present in lower OOPic versions.  Unless
> the compiler has bizarre workarounds for quirks in each OOPic version?
>
> > A new category:
> > Testing is going to be done how?  What is the testing methodology, etc?
Do
> > any of us have a suit of OOpic in the tools supported firmware
revisions?
> > If not, are we going to ask Scott Savage for a few freebies?
>
> We can probably test the bulk of our work by simply comparing the
generated
> op-codes with those from Scott's compiler, using 'equivalent' code.  This
> will be especially useful for testing object support, which I guess won't
> be changing much from the existing compiler, beyond maybe giving errors
> when someone tries to access vapourware.  Plus, I don't think testing
> against actual sonars, motors, compasses etc is going to be practical!
>
> However I guess that'll only work so far, and we'll need to do testing
> against real hardware for some stuff.  I have an OOPic II+ (b.2.2+) and an
> OOPic II (b.1.0).
>
> Perhaps for the various bits of hardware we don't have, we could recruit
> a couple of beta testers from the OOPic forum who have the required
> itarget hardware.
>
> Same applies for different development systems - for example for the
> Windows compiler we're going to have to test on Win95/98/ME/NT/2000/XP.
>
> Of course, as it's open source, I guess it's reasonable to release it
> having tested it on the hardware we have, and list the hardware it's been
> seen to work on.  Then people can test it on their own hardware and report
> back, in the true spirit of open source knowledge sharing!
>
> I think we'll be lucky if Scott gives us some freebies!
>
> > A new category:
> > Installer issues have been recently discussed on the OOpic list.  What
> > 'installer' issues will this project need to address?
>
> Well, I think the installer issue has come up because of the IDE's
> dependency on VB runtime files, which may/may not be present on a given
> system, and may not be the correct version.
>
> I'm hoping that our compiler will be pretty self-sufficient, not relying
on
> installed DLLs or libraries, and so it should be a simple operation of
> putting the compiler exe somewhere on the path.  If the compiler depends
on
> Windows DLLs etc, then we will have lost cross-platform compatibility as
> there are no equivalents to the various Windows DLLs on DOS, Linux and
> MacOS.  I think considering the target audience, it would be acceptable to
> make a static build with any libraries compiled in.
>
> I should be able to "find" a copy of InstallShield for creating a proper
> installer for Window.  For DOS, I guess we can get away with a batch file
> or similar.  And for Linux I think it would be acceptable to ship it as a
> source code .tar.gz file with compilation instructions (this is widely
> regarded as reasonable on Linux).  Alternatively it wouldn't be hard to
> create ready-compiled RPM or DEB files for Linux.
>
> One question that arises from this - are we intending to allow out
compiler
> to work as a drop-in replacement for the existing compiler, ie so that it
> works from the existing IDE.  If so, then the installer will have to
locate
> the currently-installed compiler, rename it, and replace it with the new
> one.
>
> Neil
> --
> Neil Durant
> <nd...@us...>