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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Just a quick test message to the new mailing list to see if it works
properly!  Is everyone receiving this?

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

At 02:51 AM 4/29/2004 +0100, Neil Durant wrote:
>Just a quick test message to the new mailing list to see if it works
>properly!  Is everyone receiving this?

Hm.  Can't speak for everyone, so I guess I shouldn't be replying...  :)

...Andy

Andrew Porrett wrote:
> At 02:51 AM 4/29/2004 +0100, Neil Durant wrote:
> >Just a quick test message to the new mailing list to see if it works
> >properly!  Is everyone receiving this?
> 
> Hm.  Can't speak for everyone, so I guess I shouldn't be replying...  :)

Well, using my immense powers of deduction, I can exclusively reveal that
we are all receiving!

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.

Daniel, have you had any further thoughts from the digging work you've been
doing that you mentioned to me last week?

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

* What other languages do we want to support?

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

* What platforms do we want to support?

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

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

* What extra features do we want to support?

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

Thoughts?

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

> Daniel, have you had any further thoughts from the digging work you've
been
> doing that you mentioned to me last week?

I've constructed a triplet of source files that seem to exercise the OOpicMK
compiler in the documented syntax styles Basic, C, and Java.  I'll post
these scripts and the byte-code lists soon.

I've not yet compiled the byte-codes table.

I have not yet crafted scripts that exercise the objects for the purpose of
identifying the byte-codes.

Given Scott's offer, I'll contact him before putting much further effort
into this byte-codes analysis.

Daniel

D. Daniel McGlothin wrote:
> > Daniel, have you had any further thoughts from the digging work you've
> > been doing that you mentioned to me last week?
> 
> I've constructed a triplet of source files that seem to exercise the OOpicMK
> compiler in the documented syntax styles Basic, C, and Java.  I'll post
> these scripts and the byte-code lists soon.
> 
> I've not yet compiled the byte-codes table.
> 
> I have not yet crafted scripts that exercise the objects for the purpose of
> identifying the byte-codes.
> 
> Given Scott's offer, I'll contact him before putting much further effort
> into this byte-codes analysis.

Sounds like a good idea - the data we get back from Scott may influence the
way you might want to approach the analysis.

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

I'd expect the same object opcodes in all syntax styles.

I wonder if the codes are identical across all target hardware types.

At 04:45 AM 4/29/2004 +0100, Neil Durant wrote:
>D. Daniel McGlothin wrote:
>> > Daniel, have you had any further thoughts from the digging work you've
>> > been doing that you mentioned to me last week?
>> 
>> I've constructed a triplet of source files that seem to exercise the
OOpicMK
>> compiler in the documented syntax styles Basic, C, and Java.  I'll post
>> these scripts and the byte-code lists soon.

Andrew Porrett wrote:
> I wonder if the codes are identical across all target hardware types.

I've compiled code using A.1.x in the IDE and uploaded into an OOPic II
running B.2.x+, and it's run fine, so I guess the answer is probably yes,
at least for the opcodes that appeared in my program! :-)

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

At 12:18 AM 4/29/2004 -0400, D. Daniel McGlothin wrote:

>The OOpic internally is just stack processor, and it seems that all objects,
>variables, and results of scripting is just streamed onto the stack, and the
>execution pops the byte-code and its arguments, runs the firmware bit
>related to the byte-code, and then pushes a result back to the stack.
>
>But you probably already knew that.

Yup.

>> I wonder if the codes are identical across all target hardware types.
>
>It seems so. The differences in hardware seem to be additional
>byte-codes/firmware capability as the OOpic revision 'increases'.

So it's easy then.  Is it done yet?  :)

...Andy

At 09:42 PM 4/29/2004 -0400, D. Daniel McGlothin wrote:
>> >> I wonder if the codes are identical across all target hardware types.
>> >
>> >It seems so. The differences in hardware seem to be additional
>> >byte-codes/firmware capability as the OOpic revision 'increases'.
>>
>> So it's easy then.  Is it done yet?  :)
>
>
>I sheepishly grin and and then blurt "but I'm working on the landscaping and
>garden just now."
>
>
>BTW,  what form should this information be submitted?  Sourceforge DOCS,
>e-mail attaches, or what?
>
>Daniel

No, I mean so the _whole_ compiler project is easy then.  :)

(so is it done yet?)

As far as forms go, I'm a simple ASCII .txt kinda guy, but .doc's,
spreadsheets, .html's, whatever are OK with me.

Email attachments are convenient, since they just show up by themselves
without any extra effort on my part.  Since this is such a small team, I
think we can start off rather informally and just email stuff back and
forth for now.

...Andy

Andrew Porrett wrote:
> At 09:42 PM 4/29/2004 -0400, D. Daniel McGlothin wrote:
> >> >> I wonder if the codes are identical across all target hardware types.
> >> >
> >> >It seems so. The differences in hardware seem to be additional
> >> >byte-codes/firmware capability as the OOpic revision 'increases'.
> >>
> >> So it's easy then.  Is it done yet?  :)
> >
> >
> >I sheepishly grin and and then blurt "but I'm working on the landscaping and
> >garden just now."
> >
> >
> >BTW,  what form should this information be submitted?  Sourceforge DOCS,
> >e-mail attaches, or what?
> >
> >Daniel
> 
> No, I mean so the _whole_ compiler project is easy then.  :)
> 
> (so is it done yet?)

I had half an hour to kill earlier, so I finished the whole project off,
just for kicks.  But then I accidentally deleted the folder containing all
the code.  Sorry about that...

> As far as forms go, I'm a simple ASCII .txt kinda guy, but .doc's,
> spreadsheets, .html's, whatever are OK with me.

I'm a simple ASCII guy too (meaning I'm a simple guy, and I like ASCII!),
and ASCII ensures that anyone can read it, regardless of platform.  You
never know when another developer might want to join in.

> Email attachments are convenient, since they just show up by themselves
> without any extra effort on my part.  Since this is such a small team, I
> think we can start off rather informally and just email stuff back and
> forth for now.

Agreed, although anything we're collectively working on, collaboratively,
might be better done via the site, otherwise we'll just spend all our time
throwing attachments at each other and fixing up the differences.  But
files just one of us is working on, or files sent just for reading,
attachments sound like the way to go.

Once we get onto actual source code, I guess CVS is the way to go...

Note that the mailing list currently has a 40kb limit for postings,
although I believe we can increase this if necessary.

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

At 03:35 AM 4/30/2004 +0100, Neil Durant wrote:

>I had half an hour to kill earlier, so I finished the whole project off,
>just for kicks.  But then I accidentally deleted the folder containing all
>the code.  Sorry about that...

That odd, I just had the same experience.  I guess it's up to Dan to do all
the work from this point on (it only seems fair...)

>Agreed, although anything we're collectively working on, collaboratively,
>might be better done via the site, otherwise we'll just spend all our time
>throwing attachments at each other and fixing up the differences.

Agreed, but we're not there yet, so...

Also, I suspect that we may end up just giving certain parts of the job to
one individual, so multiple users updating the same document may not be all
that common.  We'll see.

...Andy

OK, ok, I did it.

Attached is a (partial) disassembly of the bytecode stream and other files:
    BasicSyntax.osc -- human readable byte-code listing
    BASICSYNTAX.oex -- the HEX file of the above
    BASICSYNTAX.Omp -- human readable object map
    OOpic byte-codes generated by the OOpicMK compiler.xlr -- Microsoft
Works spreadsheet disassembly notes
    OOpic byte-codes generated by the OOpicMK compiler.xlr -- Microsoft
Excel 95 version of the same.
    OOpicMK_commandline.txt -- notes about the OOpicMK.exe operation

If the spreadsheets are a problem, I'll render the stuff as a text file.

Please take a look at the OEX file in a hex editor and see if the ASCII
codes of the bytes match that shown in the second 'column' of the OSC
(assembler listing).  I suspect it does.

I'll do more landscaping this weekend, as well as prepare a devotional
sermon for Sunday.  I'll plan to be back next week.

BTW,

I'm in Pennsylvania, US.

Daniel

----- Original Message -----
From: "Andrew Porrett" <wa...@ic...>
To: <oop...@li...>
Sent: Thursday, 29 April 2004 22:43
Subject: Re: [Oopic-compiler-devel] Reverse-engineering the OOpicMK
compiler--preliminary

> At 03:35 AM 4/30/2004 +0100, Neil Durant wrote:
>
> >I had half an hour to kill earlier, so I finished the whole project off,
> >just for kicks.  But then I accidentally deleted the folder containing
all
> >the code.  Sorry about that...
>
> That odd, I just had the same experience.  I guess it's up to Dan to do
all
> the work from this point on (it only seems fair...)
>
>
> >Agreed, although anything we're collectively working on, collaboratively,
> >might be better done via the site, otherwise we'll just spend all our
time
> >throwing attachments at each other and fixing up the differences.
>
> Agreed, but we're not there yet, so...
>
> Also, I suspect that we may end up just giving certain parts of the job to
> one individual, so multiple users updating the same document may not be
all
> that common.  We'll see.
>
>
> ...Andy
>
>
> -------------------------------------------------------
> 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
>

I went ahead and put the files originally attached at the URL
http://oopicide.mcglothin.info/OOpicCompilerReverseEngineering_ListOfFiles.asp

When updated, I'll mention it in a posting.

Andrew:
I haven't looked closely at what your tools did.  Do you essentially translate
the script in a preferred syntax into the OOpicMK syntax and then use the
compiler?

Or do you have your tools emit the OEX file directly--if so, then I'm wasting my
time.

Daniel

> -----Original Message-----
> From: oop...@li...
> [mailto:oop...@li...]On Behalf Of D.
> Daniel McGlothin
> Sent: Friday, April 30, 2004 8:03 AM
> To: oop...@li...
> Subject: Re: [Oopic-compiler-devel] Reverse-engineering the OOpicMK
> compiler--preliminary
>
>
> OK, ok, I did it.
>
>
> Attached is a (partial) disassembly of the bytecode stream and other files:
>     BasicSyntax.osc -- human readable byte-code listing
>     BASICSYNTAX.oex -- the HEX file of the above
>     BASICSYNTAX.Omp -- human readable object map
>     OOpic byte-codes generated by the OOpicMK compiler.xlr -- Microsoft
> Works spreadsheet disassembly notes
>     OOpic byte-codes generated by the OOpicMK compiler.xlr -- Microsoft
> Excel 95 version of the same.
>     OOpicMK_commandline.txt -- notes about the OOpicMK.exe operation
>
>
> If the spreadsheets are a problem, I'll render the stuff as a text file.
>
> Please take a look at the OEX file in a hex editor and see if the ASCII
> codes of the bytes match that shown in the second 'column' of the OSC
> (assembler listing).  I suspect it does.
>
> I'll do more landscaping this weekend, as well as prepare a devotional
> sermon for Sunday.  I'll plan to be back next week.
>
> BTW,
>
> I'm in Pennsylvania, US.
>
> Daniel
>
>
>
> ----- Original Message -----
> From: "Andrew Porrett" <wa...@ic...>
> To: <oop...@li...>
> Sent: Thursday, 29 April 2004 22:43
> Subject: Re: [Oopic-compiler-devel] Reverse-engineering the OOpicMK
> compiler--preliminary
>
>
> > At 03:35 AM 4/30/2004 +0100, Neil Durant wrote:
> >
> > >I had half an hour to kill earlier, so I finished the whole project off,
> > >just for kicks.  But then I accidentally deleted the folder containing
> all
> > >the code.  Sorry about that...
> >
> > That odd, I just had the same experience.  I guess it's up to Dan to do
> all
> > the work from this point on (it only seems fair...)
> >
> >
> > >Agreed, although anything we're collectively working on, collaboratively,
> > >might be better done via the site, otherwise we'll just spend all our
> time
> > >throwing attachments at each other and fixing up the differences.
> >
> > Agreed, but we're not there yet, so...
> >
> > Also, I suspect that we may end up just giving certain parts of the job to
> > one individual, so multiple users updating the same document may not be
> all
> > that common.  We'll see.
> >
> >
> > ...Andy
> >
> >
> > -------------------------------------------------------
> > 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
> >
>

At 03:24 PM 4/30/2004 -0400, D. Daniel McGlothin wrote:
>Andrew:
>I haven't looked closely at what your tools did.  Do you essentially
translate
>the script in a preferred syntax into the OOpicMK syntax and then use the
>compiler?

Yup.

>Or do you have your tools emit the OEX file directly--if so, then I'm
wasting my
>time.

Not likely!

...Andy

D. Daniel McGlothin wrote:
> OK, ok, I did it.
> 
> 
> Attached is a (partial) disassembly of the bytecode stream and other files:
>     BasicSyntax.osc -- human readable byte-code listing
>     BASICSYNTAX.oex -- the HEX file of the above
>     BASICSYNTAX.Omp -- human readable object map
>     OOpic byte-codes generated by the OOpicMK compiler.xlr -- Microsoft
> Works spreadsheet disassembly notes
>     OOpic byte-codes generated by the OOpicMK compiler.xlr -- Microsoft
> Excel 95 version of the same.
>     OOpicMK_commandline.txt -- notes about the OOpicMK.exe operation
> 
> 
> If the spreadsheets are a problem, I'll render the stuff as a text file.
> 
> Please take a look at the OEX file in a hex editor and see if the ASCII
> codes of the bytes match that shown in the second 'column' of the OSC
> (assembler listing).  I suspect it does.

Excellent work!!!  I have written a little Perl utility to read in a .Ops
opcode file, and generate a .hex file containing the opcode bytes nicely
tabulated in hex format.  To use it, just type:

  perl ops2hex.pl BASICSYNTAX.Ops  (or whatever file you're converting)

and a corresponding .hex file will be generated.

I have checked, and the generated hex (from the op-codes file) matches the
OEX file perfectly.

I've attached the perl utility and the .hex file,

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

> I'd expect the same object opcodes in all syntax styles.

It is with the official syntax variations.

The OOpic internally is just stack processor, and it seems that all objects,
variables, and results of scripting is just streamed onto the stack, and the
execution pops the byte-code and its arguments, runs the firmware bit
related to the byte-code, and then pushes a result back to the stack.

But you probably already knew that.

> I wonder if the codes are identical across all target hardware types.

It seems so. The differences in hardware seem to be additional
byte-codes/firmware capability as the OOpic revision 'increases'.

Daniel

> >> I wonder if the codes are identical across all target hardware types.
> >
> >It seems so. The differences in hardware seem to be additional
> >byte-codes/firmware capability as the OOpic revision 'increases'.
>
> So it's easy then.  Is it done yet?  :)

I sheepishly grin and and then blurt "but I'm working on the landscaping and
garden just now."

BTW,  what form should this information be submitted?  Sourceforge DOCS,
e-mail attaches, or what?

Daniel

In-line reply style....(and these are just my opinion).

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

K&Rv1 at minimum, downgraded to fit the micro.

No matter which script(s) we choose, we will have the same problems that
Savage is hammered for--"but you didn't include ____".

I suggest starting with one (see below).

> * What other languages do we want to support?

No need to do a visual one, seems that Scott's well on the way with that
one.

I'm indifferent to additional scripting syntax (see below).

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

This is just another way of asking what language to support.

> * What platforms do we want to support?

I'm agnostic about this.  A DOS/Windows command line is sufficient.  I can
use UltraEdit and Makefiles for my 'IDE'.

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

I've been around long enough to have, at one time, established fluency in
languages whose initials would consume much of the alphabet.  C is probably
common denominator.

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

(target of 'see below')
Why not.  These would allow the automatic generation of much of the effort
based on a grammer definition.  And as we would publish the inputs to these
tools, a knowledgabel person could independantly extend the scripting tool
to suit themselves.

I'was reading a quick into to compiler writing using these tools just
recently.  I'll look the URL up.

> * What extra features do we want to support?

I might suggest the script clearly differentiate between the VC and the
interpreted code.
Something like the Delphi unit divisions (e.g., implementation,
initialization, finalization keywords -- reference
http://delphi.about.com/library/weekly/aa061802b.htm)

Include files.  Other standard C-preprocessor stuff.

Libraries of routines, both VC and slow-script stuff.

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

Dennis Clark's bug list should be inspected.  Recently James L Harris
(22-APR-2004) published a seriesl of un-addressed issues in the IDE--these
should be considered.

If we do not advance the 'state of the art', our effort may be personally
satisfying, but probably generally useless.

New item on list:

Are we making a collection of command line tools, or are we considering an
IDE?

My vote is command line tools, similar to Andrew's recently exposed work.

Daniel

D. Daniel McGlothin wrote:
> > * What level of C language support are we aiming for?  Full ANSI C (minus
> >   floats etc) ?
> 
> No matter which script(s) we choose, we will have the same problems that
> Savage is hammered for--"but you didn't include ____".

True - but unlike Scott, we'll probably implement them and make a new
release.  Or someone else could, if they were that keen.

> > * Do we want a mode that allows "standard" OOPic BASIC/C/JAVA to be
> >   compiled?
> 
> This is just another way of asking what language to support.

Well, except that going for K&R style compatibility will break
compatability with OOPIC C.  I like Andrew's idea of a preprocessor to turn
OOPIC C into our more correct C.

> > * What implementation language(s) do we want to use?
> 
> I've been around long enough to have, at one time, established fluency in
> languages whose initials would consume much of the alphabet.  C is probably
> common denominator.

OK, it sounds like we're all in agreement here!  Lucky...

> > * What extra features do we want to support?
> 
> I might suggest the script clearly differentiate between the VC and the
> interpreted code.
> Something like the Delphi unit divisions (e.g., implementation,
> initialization, finalization keywords -- reference
> http://delphi.about.com/library/weekly/aa061802b.htm)

Interesting idea - although I guess the more we add, the more people may
think "Eugh, what's this?" and stuck with what they know.  Maybe we should
say that any extra features are fine as long as they're not obligatory?

> New item on list:
> 
> Are we making a collection of command line tools, or are we considering an
> IDE?
> 
> My vote is command line tools, similar to Andrew's recently exposed work.

My vote would be command line tools also.  If we (or someonee else) ever
get round to writing a decent IDE for the OOPic, then it can call our
command-line tools itself.  It's the most flexible way.  Also, any
half-decent programmer's editor will have the capability to launch a
compiler.

New item on list:

* Makefiles - Thoughts?

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

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

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

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

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

Perhaps I could exercise the required 'diplomancy'.

In any case, I agree it might be a bit premature.  This effort started with
a bit of a splash, and it seems that the existance of this effort is known.
It might be worth getting just a bit further to demonstrate that this is not
just a 'flash in the pan'.

Doesn't Sourceforge give a mechanism that could be used to capture the bug
list or requested features.

Daniel

D. Daniel McGlothin wrote:
> > >> 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.
> 
> Perhaps I could exercise the required 'diplomancy'.
> 
> In any case, I agree it might be a bit premature.  This effort started with
> a bit of a splash, and it seems that the existance of this effort is known.
> It might be worth getting just a bit further to demonstrate that this is not
> just a 'flash in the pan'.

Agreed.  Let's put some work into a really well thought out feature list
and present it only when we're pretty sure we can implement these things
(ie after seeing the op-code definitions and some subsequent pondering).
Then we can "go public" with our plans and it won't look like
vapourware/dreamware.

> Doesn't Sourceforge give a mechanism that could be used to capture the bug
> list or requested features.

Yes, just click the "Feature requests" or "Bugs" links on the main project
page.  It looks pretty easy to add feature requests and bug notifications.

Neil

PS: What time zones are you guys in?  It's 3.30am at this end (England).
You guys seem to start a posting frenzy from about midnight my time!
-- 
Neil Durant
<nd...@us...>

At 03:29 AM 4/30/2004 +0100, Neil Durant wrote:
>PS: What time zones are you guys in?  It's 3.30am at this end (England).
>You guys seem to start a posting frenzy from about midnight my time!

It's 10:30pm in Toronto, and I'm _still_ at the office...

I think I'll go home soon.

(what are you doing up at 3:30am???)

...Andy