oopic-compiler-devel Mailing List for OOPic Compiler (Page 5)
Status: Planning
Brought to you by:
ndurant
Menu
▾
▴
oopic-compiler-devel — A mailing list for discussion of design and development of the OOPic compiler
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(36) |
May
(52) |
Jun
(17) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(6) |
|---|
|
From: Neil D. <nd...@us...> - 2004-04-29 04:29:41
|
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...> |
|
From: D. D. M. <dd...@mc...> - 2004-04-29 04:18:59
|
> 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 |
|
From: Neil D. <nd...@us...> - 2004-04-29 04:18:01
|
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...> |
|
From: Neil D. <nd...@us...> - 2004-04-29 04:15:39
|
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...>
|
|
From: D. D. M. <dd...@mc...> - 2004-04-29 04:05:57
|
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 |
|
From: Andrew P. <wa...@ic...> - 2004-04-29 04:00:35
|
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. |
|
From: Neil D. <nd...@us...> - 2004-04-29 03:45:47
|
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...> |
|
From: D. D. M. <dd...@mc...> - 2004-04-29 03:32:50
|
> 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 |
|
From: Andrew P. <wa...@ic...> - 2004-04-29 03:31:52
|
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 |
|
From: D. D. M. <dd...@mc...> - 2004-04-29 03:04:08
|
Neil, Have you yet made a formal and specific request for Scott Savage's assistence for this project, based on his following? <quote> If you guys want to put together a full blown C language compiler, you will have my full support. No need to reverse engineer the compiler. Just ask for whatever you need. I will release the native code instructions and the Object definitions for your developer's group. </quote> If no, do you want me to? Daniel |
|
From: Neil D. <nd...@us...> - 2004-04-29 02:58:49
|
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...> |
|
From: D. D. M. <dd...@mc...> - 2004-04-29 02:46:30
|
This portion of everyone has received it. Daniel ----- Original Message ----- From: "Neil Durant" <nd...@us...> To: <oop...@li...> Sent: Wednesday, 28 April 2004 21:51 Subject: [Oopic-compiler-devel] Testing... > 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...> > > > ------------------------------------------------------- > 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 > > |
|
From: Andrew P. <wa...@ic...> - 2004-04-29 02:25:12
|
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 |
|
From: Neil D. <nd...@us...> - 2004-04-29 01:51:15
|
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...> |
