Re: [Oopic-compiler-devel] Testing...

[Andrew P. <wa...@ic...>]

At 03:58 AM 4/29/2004 +0100, Neil Durant wrote:
>So where do we start?  I guess Scott's revelation on the OOPic forum that
>he'll give us any information we need sounds promising, and should minimise
>any reverse-engineering headaches.  However we can't bank on getting full,
>complete and accurate data from him, so we may have to do some digging
>ourselves too.

Anything he gives us needs to be double checked where possible.
I know he makes the odd mistake.


>Also, some possible things we might want to discuss:
>
>* What level of C language support are we aiming for?  Full ANSI C (minus
>  floats etc) ?

Full ANSI C is not going to happen.  The OOPic doesn't support things like
local variables on a stack and I'm sure there's lots more we can't do easily.

Do we need structures and unions, for example?


>* What other languages do we want to support?

My interests are pretty much C.  Have any non-developers asked us for other
languages yet?


>* Do we want a mode that allows "standard" OOPic BASIC/C/JAVA to be
>  compiled?

You should be able to convert OOPic C to real C with a preprocessor (or was
it the other way around?? :)

 
>* What platforms do we want to support?

I'm guessing we want DOS, Windows, Linux, and maybe Mac?


>* What implementation language(s) do we want to use?

If it's not C, I'm in trouble.


>* Should we use a compiler compiler, such as flex/bison/lex/yacc ?

Tough call.  Can we learn to use these quickly?  Will they let us produce
optimized code?


>* What extra features do we want to support?

Inline functions would be nice.  We get to have clean looking source but
don't incur the overhead of function calls.

Word / byte / bit arrays in EEPROM via direct references rather than
function calls:

  EEbyte table[100];  // allocate array in EEPROM

  table[i] = n;  // directly access array

Stuff like that would be nice.

If the OOPic interpreter can handle shift operators, we can finally use
them (hopefully, it's just the compiler that's broken).

Are we going to ask the community what they'd like to see?


>* What bugs in the existing languages do we specifically want to address?

All that we know of?  Lack of local namespaces, yadda, yadda...


...Andy