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

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

Andrew Porrett wrote:
> At 03:58 AM 4/29/2004 +0100, Neil Durant wrote:
> >* 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.

There may be some things we can fudge - for example most C programmers
don't *need* local variables to be implemented using a stack.  We could
make them global, with some name mangling to ensure uniqueness, and give
them the semantic appearence of local scope, including variables of the
same name in nested blocks etc.

> Do we need structures and unions, for example?

Yeah, there's probably not much desire for this kind of thing, but we could
have such features as long-term wish-list items, to be implemented if and
when required.

> >* What other languages do we want to support?
> 
> My interests are pretty much C.  Have any non-developers asked us for other
> languages yet?

Not to my knowledge, but the vast majority of OOPic users are using BASIC,
and I would guess our compiler would be embraced more if it supported
BASIC.  My interests are entirely C also, but the more generic the appeal,
the more support we'll get, the more likely other developers will join in
and help, and (perhaps most importantly) the more bug reports we'll get as
we'll have a substantially larger group of testers out there.

With careful design, we should be able to make language support modular, so
that a BASIC parser could be fitted onto the same engine that generates the
op-codes.

I haven't heard of anyone using Java on the OOPic 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?

I've had a couple of e-mails from Mac users on the forum, who were giving
their verbal support to our project, both saying that they hate having to
use Windows for OOPic work.

We should consider what options we have for cross-platform development, eg
any libraries we may need etc.  There's a GNU gcc compiler for all of those
platforms, and I believe flex/bison work on all too.

I have several Linux machines, a Mac, and a Win2k box at my disposal for
building/testing purposes.

> >* What implementation language(s) do we want to use?
> 
> If it's not C, I'm in trouble.

I'm primarily a C++ person, although I was originally a C person for many
years.  If we use a compiler-compiler such as flex/bison (discussed later)
then they nearly all generate C code for the parsers etc, so C sounds like
the best option.

> >* 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?

I've used flex/bison before, but not for a while.  I also used a beautiful
object-oriented C++ compiler compiler which allowed you to define the
entire language grammar using objects, although there were some stability
issues.

From my experience with flex/bison, they're pretty quick and easy to get
started with, and they would allow us to quickly build up the language
grammar we desire using regular expressions.  As for producing optimised
code, according to my understanding they don't actually generate the code -
they just parse the grammar and allow you to call functions when certain
grammar constructs are found, and then it's up to you to create the most
optimal code for that grammar construct.

> >* 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.

Agreed.

> 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.

Definitely! :-)

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

Indeed.

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

Sounds like a good idea.  Would you like to post something?

> >* What bugs in the existing languages do we specifically want to address?
> 
> All that we know of?  Lack of local namespaces, yadda, yadda...

One thing I was thinking about was making the user class idea a little more
object oriented (taking ideas from C++).  For example being able to create
user class objects with "constructors", ie the ability to pass in
parameters when you first create the object, which are then used during a
"constructor" function (currently main()) within the user class.  So you
could do something like:

  oUserClass myObj = new oUserClass("myClass.osc", 2, 20);

...and the 2 and the 20 get passed into the user class's constructor
function.

Thinking further, real C++ style objects could be created, by abandoning
this special oUserClass object, and allowing user classes to have their own
type names.  So you could declare a user class (using a "class" keyword) as
follows (this is a very rough example off the top of my head):

	/* MyClass.h */
	
	class MyClass
	{
		int value;
		
		Constructor(int x)
		{
		  /* This gets called when a MyClass object is created */
		  /* x may be used to set up the object */
		  value = x;
		}

		void SomeFunc()
		{
		  /* Some function */
		}
	}

And then you would define an object of this type with:

	#include "MyClass.h"
	
	MyClass theClass = new MyClass(5); /* Passes 5 into constructor */
	theClass.SomeFunc();
	int a = theClass.value;

	...etc


It's not at all C-like, and has many resemblences to C++, but an extension
like this might be useful as a way to rationalise the user class
functionality.  It would certainly make the "OO" in OOPic a bit more
justifiable! :-)

Thoughts?

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