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

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

At 05:15 AM 4/29/2004 +0100, Neil Durant wrote:

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

You have to be careful with auto variables.  If you silently make them
static, you'll run out of RAM real fast.  Looks like we may be stuck doing
this anyway.  I doubt that the interpreter can deal with data at a variable
address.


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

I guess I could see a need for unions - "I need a word variable here, but
there's no more RAM.  If only I could reuse those two bytes..."


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

I have no problem with BASIC, but I wonder how many BASIC users would try
our approach.  Obviously, there will be some, as they'd want to get around
some of the compiler bugs (array sizes, broken nested switch constructs, ...)


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

One guy just inquired about it...


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

Sounds reasonable.


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

Cool.


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

Sounds good.  I suspect that the latter area is where more of my efforts
will go.


>> >* What extra features do we want to support?

We're going to have to take a good look at ALL the opcodes used by the
interpreter in order to see what sort of cool stuff we can come up with.


>> Are we going to ask the community what they'd like to see?
>
>Sounds like a good idea.  Would you like to post something?

Doh!  I'm not the diplomatic one.  I also think it's a bit early for that.
I thought we'd come up with our overall feature plan and present it for
review.


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

I think that it's not C anymore, but I don't have a huge problem with that.

My immediate thoughts are:
- where does this thing get constructed?  RAM?  EEPROM?
- when does it get constructed?  If it's only at program startup, the "new"
seems like a fib.
- can this thing get deleted?
- is there a significant advantage to this approach, or is it just
something that appeals to a OOP guy?

Some real world examples would help me here...


...Andy