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
>