oopic-compiler-devel Mailing List for OOPic Compiler (Page 3)
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-05-12 01:49:43
|
D. Daniel McGlothin wrote: > A couple of quick thoughts. > > 1. lack of support for the three syntax styles Savage implemented is > probably a non-starter (unless we have the IDE selecting between the OOpicMK > compiler and this one). As it is now, the user must specify the syntax; we > can require the same as a command line. Or possibly use a token in the > sourcecode similar to what Parallax did with their new PBasic syntax and the > firmware revisions, and let the preprocessor pick it out. Agreed. We could also have the syntax selected implicitly based on the file extension. There's no reason why we need to stick with .osc file extensions - we could use .c, .bas, .java or whatever. Or perhaps a combination - if it's explicitly specified on the command line, use that, if not then check for a token in the source, and failing that use the file extension. And failing that, assume it's C! > 2. After those, the grammer for an (or many) arbitrary syntax could be > defined. > > 3. In all cases, the compiler tools yield a similar internal representation > that is subjected to code generation and optimization. Agreed. Many compilers that support multiple input languages (eg gcc) separate the internal representation generation from the code generation and optimisation, and I think it would be wise for us to do the same. I think C, BASIC and Java are similar enough to allow identical internal representation. We would effectively have a number of different "front ends" that convert input code into an internal structure. > For the original scripts' syntax, should we generate identical code to > the OOpicMK or use our own? I'm not sure I understand what you mean (it's 2.44am here - brain fade!) > 4. Does the grammer specification require some (or deep) knowledge of the > possible syntactical structures the native byte-codes would permit? If so, > then I should get some more work done. I don't think so - the grammar specification should be pretty much like the standard C grammar (for C language support) which we can obtain from C syntax documents in various places. The format Flex/Bison take is very similar to the syntax used in syntax standards documents, so it should be fairly straightforward to implement a full C parser. For BASIC and Java I guess we just play it by ear...! My understanding is that the grammar specification should be fairly well isolated from the native byte-code. The byte code looks sufficiently low-level to be flexible. We know it's possible to implement the current OOPIC scripting language constructs in OOPIC byte code, after all. Perhaps we'll discover things that are hard or even impossible to implement in byte code, but we may only find out when we try.... Neil -- Neil Durant <nd...@us...> |
|
From: Andrew P. <wa...@ic...> - 2004-05-12 01:25:15
|
Don't know very much about compiler design. Assumed we would do pretty much what you outlined. I expect my expertise will come into play more when we get around to code generation and optimization. At 01:45 AM 5/12/2004 +0100, Neil Durant wrote: >Did either have you have any ideas on the overall design of the compiler? |
|
From: D. D. M. <dd...@mc...> - 2004-05-12 01:19:02
|
A couple of quick thoughts. 1. lack of support for the three syntax styles Savage implemented is probably a non-starter (unless we have the IDE selecting between the OOpicMK compiler and this one). As it is now, the user must specify the syntax; we can require the same as a command line. Or possibly use a token in the sourcecode similar to what Parallax did with their new PBasic syntax and the firmware revisions, and let the preprocessor pick it out. 2. After those, the grammer for an (or many) arbitrary syntax could be defined. 3. In all cases, the compiler tools yield a similar internal representation that is subjected to code generation and optimization. For the original scripts' syntax, should we generate identical code to the OOpicMK or use our own? 4. Does the grammer specification require some (or deep) knowledge of the possible syntactical structures the native byte-codes would permit? If so, then I should get some more work done. Daniel ----- Original Message ----- From: "Neil Durant" <nd...@us...> To: "OOPic Compiler List" <oop...@li...> Sent: Tuesday, 11 May 2004 20:45 Subject: [Oopic-compiler-devel] Compiler design > Did either have you have any ideas on the overall design of the compiler? > I've been re-reading my book on Flex/Bison, and it would definitely be a > big time-saver using those tools. They would generate the C code for > parsing the grammar we provide (in a simple notation), and allow us to call > functions when the various semantic constructs are encountered. That way > we can build up a parse tree and populate symbol tables, and the > subsequently walk the tree generating code. We could then add an > optimisation stage that checks through the Forth-like codes to see if > anything silly is being done. > > This is the basic idea I have in mind, although I know there's a heck of a > lot of detail I've just hopped over! I'd be interested to hear how you > guys envisioned how the compiler would be structured. > > Thoughts? > > Neil > -- > Neil Durant > <nd...@us...> > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver > higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > |
|
From: Neil D. <nd...@us...> - 2004-05-12 00:45:40
|
Did either have you have any ideas on the overall design of the compiler? I've been re-reading my book on Flex/Bison, and it would definitely be a big time-saver using those tools. They would generate the C code for parsing the grammar we provide (in a simple notation), and allow us to call functions when the various semantic constructs are encountered. That way we can build up a parse tree and populate symbol tables, and the subsequently walk the tree generating code. We could then add an optimisation stage that checks through the Forth-like codes to see if anything silly is being done. This is the basic idea I have in mind, although I know there's a heck of a lot of detail I've just hopped over! I'd be interested to hear how you guys envisioned how the compiler would be structured. Thoughts? Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <sf...@oc...> - 2004-05-08 13:34:26
|
How disciplined and rigid we do it is up to us - the important thing I had in mind was simply recording the basic concept behind any idea or feature we decide we're going to implement, in the feature request list. I guess the discussion can carry on via this mailing list, as normal. Agreed about polling sourceforge!! Neil D. Daniel McGlothin wrote: > Good idea. Then discussion-list threads with a subject for each 'feature > name' could be started to ruminate over the feature. We would just need the > discipline to keep 'on topic' within that feature's thread. > > Unless the feature list provides for such a discussion. > > However we do it, I personally don't want to have to poll sourceforge much, > I'd rather have a list push the info to me. > > Daniel > > ----- Original Message ----- > From: "Neil Durant" <nd...@us...> > To: "OOPic Compiler List" <oop...@li...> > Sent: Saturday, 08 May 2004 03:09 > Subject: [Oopic-compiler-devel] Feature requests > > > > I was wondering - do you think we should use Sourceforge's "Feature > > requests" system for keeping track of our various ideas for features we > > want to implement in the compiler? > > > > I'm specifically thinking about things like any OOPic-specific language > > support beyond standard C we want to include, any special handling of > > objects etc etc. > > > > I thought it might be a good idea because otherwise any ideas we discuss > > might just get lost in the archives of this mailing list, never to be > > remembered again! > > > > When we get round to approaching the OOPic forum with our proposed feature > > list, and request additional ideas, we can then use the contents of the > > Sourceforge list as a starting point. > > > > Thoughts? > > > > Neil > > -- > > Neil Durant > > <nd...@us...> > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by Sleepycat Software > > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver > > higher performing products faster, at low TCO. > > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > > _______________________________________________ > > Oopic-compiler-devel mailing list > > Oop...@li... > > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > > > > -- Neil Durant <sf...@oc...> Octrix Software Ltd. |
|
From: D. D. M. <dd...@mc...> - 2004-05-08 11:49:42
|
I smiled too when I saw that. I presume it is a spell-check attempt at a mangled 'binarily' as an adverbal form of 'binary'. Put 'binarily' into www.dictionary.com and see what comes out. Daniel ----- Original Message ----- From: "Neil Durant" <nd...@us...> To: "OOPic Compiler List" <oop...@li...> Sent: Saturday, 08 May 2004 03:19 Subject: [Oopic-compiler-devel] Binaurally?! > I can't help noticing that op-codes 141 and 151 are documented as > "binaurally" ANDing and ORing stack items. Doesn't this mean the OOPic > uses two ears to carry out the operation?! > > <http://dictionary.reference.com/search?q=binaurally> > > Neil > -- > Neil Durant > <nd...@us...> > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver > higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > |
|
From: Neil D. <nd...@us...> - 2004-05-08 08:57:29
|
Backtracking a little... Andrew Porrett wrote: > At 05:15 AM 4/29/2004 +0100, Neil Durant wrote: > >One thing I was thinking about was making the user class idea a little more > >object oriented (taking ideas from C++). [snip] > >And then you would define an object of this type with: > > > > #include "MyClass.h" > > > > MyClass theClass = new MyClass(); [snip] > - is there a significant advantage to this approach, or is it just > something that appeals to a OOP guy? I've just thought of a *huge* advantage to this technique!!! Currently user classes cannot call functions defined within the user class itself, and they cannot refer to the OOPIC object itself (restrictions outlined on page 73 of Dennis' book). However using the ideas I described, we can define a 'this' pointer, which is implicit, and valid within the definition of a user class, and always refers to the object that has been created. 'this' would become a reserved word. If you create two instances of the same user class, the 'this' pointer in each class would refer to the two oUserClass objects. The compiler then knows which object is being referenced within the user class, thus allowing user classes to call their own functions, and to refer to the OOPIC object. They can therefore become true self-contained reusable pieces of code. And we can stop fiddling about with those stupid for loops when we need delays in user classes! This is an idea taken directly from C++/Java/Smalltalk. I don't know why Scott didn't implement it in oUserClass in the first place! Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-08 07:19:09
|
I can't help noticing that op-codes 141 and 151 are documented as "binaurally" ANDing and ORing stack items. Doesn't this mean the OOPic uses two ears to carry out the operation?! <http://dictionary.reference.com/search?q=binaurally> Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-08 07:09:45
|
I was wondering - do you think we should use Sourceforge's "Feature requests" system for keeping track of our various ideas for features we want to implement in the compiler? I'm specifically thinking about things like any OOPic-specific language support beyond standard C we want to include, any special handling of objects etc etc. I thought it might be a good idea because otherwise any ideas we discuss might just get lost in the archives of this mailing list, never to be remembered again! When we get round to approaching the OOPic forum with our proposed feature list, and request additional ideas, we can then use the contents of the Sourceforge list as a starting point. Thoughts? Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-08 07:04:31
|
I've uploaded those two HTML files (object property list and op-codes list) to the "Project Documentation" page on Sourceforge, just so we have a central copy. I've also granted us all admin rights to the Sourceforge documentation manager, which means we can all upload/edit documents. We can store plain text and HTML files. We can also specify whether uploaded files are private to us, or publicly viewable. Regards, Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-06 10:51:09
|
Yahoo Junk wrote: > Neil, > > > But what would "background" actually mean to the function? The OOPic > > can't execute these functions in the background, so it could be > > misleading. > > The 'background' would be nothing more than a script syntax to clearly > identify that this bit o' script is (part of) a virtual circuit. Perhaps > another token could be used, such as 'virtual_circuit'. The thought is to > clearly seperate in the syntax the VC stuff from the slower scripted stuff. > That division would have helped me grasp the VC concept sooner; maybe it > would help others too (I'm recalling Scotts comment that at Trinity > Firefighting none of the OOpics were using VC). Again, it could be misleading because the code in those 'background' functions are normal script, and running at normal slow script speed. Also, suppose you have one of these background functions that gets called when some virtual circuit triggers an event. There's nothing to stop you calling an 'ordinary' function from within that 'background' function, which blurs the line between the background stuff and the ordinary stuff. > > Are you suggesting that basically the above example would translate > > into an oWire and an oEvent, triggered by the button press? If so, > > then it's a nice idea, and cleans up the messy way you have to wire up > > oEvents. > > I'm not sure at all about whether I mean that. <grin> I'm a VC novice. > > I actually was looking for a possible syntax to seperate VC from the rest. I don't think you can though, because the code you'd be putting in a VC is still ordinary script. > > The thing I dislike about this syntax is that the use of "background" > > implies that the first statement in the function must be an "if", which > > seems a bit kludgey to me. Unless I'm misunderstanding you. > > Your event_table idea is attractive. > > Would there be (asks the VC ignorant guy) situations where a VC would > simply need to be setup and it runs autonomously? Even then, I suppose > that an .Operate interface might be required/desired. Yes, I would say this is a standard use of VCs. Quite often you call a setup() function in your script at startup that wires up the VCs, call .Operate() on them, to get them going, and then leaves them to do their work. Not all VC setups need to trigger events in script code. And in an ideal world, programs would call setup() and then end because all of the functionality would be handled within VCs, with no calling of script code at all. Neil -- Neil Durant <nd...@us...> |
|
From: Yahoo J. <Yah...@mc...> - 2004-05-06 10:28:11
|
Neil,
> But what would "background" actually mean to the function? The OOPic
can't
> execute these functions in the background, so it could be misleading.
The 'background' would be nothing more than a script syntax to clearly
identify that this bit o' script is (part of) a virtual circuit. Perhaps
another token could be used, such as 'virtual_circuit'. The thought is to
clearly seperate in the syntax the VC stuff from the slower scripted stuff.
That division would have helped me grasp the VC concept sooner; maybe it
would help others too (I'm recalling Scotts comment that at Trinity
Firefighting none of the OOpics were using VC).
> Are you suggesting that basically the above example would translate into
an
> oWire and an oEvent, triggered by the button press? If so, then it's a
> nice idea, and cleans up the messy way you have to wire up oEvents.
I'm not sure at all about whether I mean that. <grin> I'm a VC novice.
I actually was looking for a possible syntax to seperate VC from the rest.
> The thing I dislike about this syntax is that the use of "background"
> implies that the first statement in the function must be an "if", which
> seems a bit kludgey to me. Unless I'm misunderstanding you.
Your event_table idea is attractive.
Would there be (asks the VC ignorant guy) situations where a VC would simply
need to be setup and it runs autonomously? Even then, I suppose that an
.Operate interface might be required/desired.
Daniel
----- Original Message -----
From: "Neil Durant" <nd...@us...>
To: <oop...@li...>
Sent: Wednesday, 05 May 2004 22:31
Subject: Re: [Oopic-compiler-devel] Re: [oopic] Re: Oopic compiler issues -
The low down.
> > Dan Sandberg wrote:
> >> With the THEORETICAL syntax I was mentioning earlier,
> >> combined with the kinda of objects that the OOPic
> >> already supports, we could do something like this:
> >>
> >> background void activateSolenoid() {
> >> if ( button.pressed ) {
> >> solenoid = true;
> >> solenoidTimer = 5;
> >> solenoidTimer.operate = true;
> >> }
> >> }
> >> background void deactiveateSolenoid() {
> >> if ( solenoidTimer.operate and solenoidTimer == 0 ) {
> >> solenoid = false;
> >> solenoidTimer.operate = false;
> >> }
> >> }
>
>
> D. Daniel McGlothin wrote:
> > The more I think about Dan Sandberg's idea, I like it.
> >
> > The notation of 'background' as an attribute of the routine is
essentially
> > what I was thinking of with my Delphi unit 'sections' approach.
>
> But what would "background" actually mean to the function? The OOPic
can't
> execute these functions in the background, so it could be misleading.
>
> Are you suggesting that basically the above example would translate into
an
> oWire and an oEvent, triggered by the button press? If so, then it's a
> nice idea, and cleans up the messy way you have to wire up oEvents.
>
> The thing I dislike about this syntax is that the use of "background"
> implies that the first statement in the function must be an "if", which
> seems a bit kludgey to me. Unless I'm misunderstanding you.
>
> Another alternative would be to use an "event table", which would work a
> bit like the message map system in MFC, if you've used MFC. Basically
> syntax along these lines (either transformed by preprocessor or within the
> compiler itself):
>
> EVENT_TABLE
> {
> LINK(button.pressed, activateSolenoid)
> }
>
> void activateSolenoid()
> {
> solenoid = true;
> solenoidT8mer = 5;
> solenoidTimer.operate = true;
> }
>
> ...which would link "button.pressed" to a function (oEvent handler) called
> activateSolenoid. The first parameter of the LINK macro would be an
> attribute of a named object.
>
>
> The problem is that translating stuff into oEvent handlers will only work
> if the "if" clauses can be easily converted into virtual circuits, and so
> the whole thing can operate in the "background". If the "if" clause
relies
> on scripting language expressions, then it would be non-trivial to make it
> an entirely backgrounded piece of code.
>
> Neil
> --
> Neil Durant
> <nd...@us...>
|
|
From: Neil D. <nd...@us...> - 2004-05-06 02:31:56
|
> Dan Sandberg wrote:
>> With the THEORETICAL syntax I was mentioning earlier,
>> combined with the kinda of objects that the OOPic
>> already supports, we could do something like this:
>>
>> background void activateSolenoid() {
>> if ( button.pressed ) {
>> solenoid = true;
>> solenoidTimer = 5;
>> solenoidTimer.operate = true;
>> }
>> }
>> background void deactiveateSolenoid() {
>> if ( solenoidTimer.operate and solenoidTimer == 0 ) {
>> solenoid = false;
>> solenoidTimer.operate = false;
>> }
>> }
D. Daniel McGlothin wrote:
> The more I think about Dan Sandberg's idea, I like it.
>
> The notation of 'background' as an attribute of the routine is essentially
> what I was thinking of with my Delphi unit 'sections' approach.
But what would "background" actually mean to the function? The OOPic can't
execute these functions in the background, so it could be misleading.
Are you suggesting that basically the above example would translate into an
oWire and an oEvent, triggered by the button press? If so, then it's a
nice idea, and cleans up the messy way you have to wire up oEvents.
The thing I dislike about this syntax is that the use of "background"
implies that the first statement in the function must be an "if", which
seems a bit kludgey to me. Unless I'm misunderstanding you.
Another alternative would be to use an "event table", which would work a
bit like the message map system in MFC, if you've used MFC. Basically
syntax along these lines (either transformed by preprocessor or within the
compiler itself):
EVENT_TABLE
{
LINK(button.pressed, activateSolenoid)
}
void activateSolenoid()
{
solenoid = true;
solenoidT8mer = 5;
solenoidTimer.operate = true;
}
...which would link "button.pressed" to a function (oEvent handler) called
activateSolenoid. The first parameter of the LINK macro would be an
attribute of a named object.
The problem is that translating stuff into oEvent handlers will only work
if the "if" clauses can be easily converted into virtual circuits, and so
the whole thing can operate in the "background". If the "if" clause relies
on scripting language expressions, then it would be non-trivial to make it
an entirely backgrounded piece of code.
Neil
--
Neil Durant
<nd...@us...>
|
|
From: Neil D. <nd...@us...> - 2004-05-06 02:19:09
|
Scott Savage wrote: >> You will be able to reuse object memory in the new GUI IDE. Not create >> and destroy objects mind you, but you will be able to change the object >> configuration from one configuration to another configuration. D. Daniel McGlothin wrote: > Either of you are better experienced in the use of the objectsn and the > virtual circuits than I (I have not even downloaded a program to my lonely > OOpic). > > What is your take on this statement by Scott. I've half of an idea how this > might be done, but do either of you see an implication of new firmware to > support this? We should put our thoughts together for a question I can pose > to Scott. Well it sounds to me like he's planning on providing a way to swap out some or all of the active objects from object RAM to EEPROM, and replace them with another set from EEPROM. If that's the case, it seems like a rather cumbersome solution to the limited object memory issue, although I can imagine situations where it could be useful. One problem I see is that presumably the swap would be triggered by a command in the script (perhaps a new OOPIC object method), which would mean there would be little control over exactly when the objects were changed over (as there's no real sense of synchronisation between the virtual circuitry and the scripting language). So it would be difficult to ensure hardware is all in a consistent state before changeover. I'm sure Scott is pondering these very issues. Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-06 02:10:55
|
D. Daniel McGlothin wrote: > You might each want to take your local snapshot of the page Scott has > provided, in case this is a temporary URL. Good idea - done. > This confirms that my analysis I posted last week--using this will be much > more convient than hard thinking for the byte-code reverse engineering. > I'll now concentrate on the objects and the byte-code emitted as a result of > script syntax examples. Good move. Incidentally it might be useful for us to implement a really trivial compiler that converts Forth-like syntax directly into op-codes. In other words basically come up with a set of suitable 1-word names for the contents of the "function" column, and map those names directly to op-codes. This would be useful for experimenting, and may also be a useful intermediate code to generate from the full C compiler. > Also, I've requested the Access database, but it may not be much more than > what was posted on the OOpic list a week or so ago (that link was > http://www.oopic.com/ObjectPropListo.html). Well, it will be interesting to see what it is, anyway. So he didn't say anything about items 3-10 ??!! Neil -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-05-06 01:18:45
|
Either of you are better experienced in the use of the objectsn and the virtual circuits than I (I have not even downloaded a program to my lonely OOpic). What is your take on this statement by Scott. I've half of an idea how this might be done, but do either of you see an implication of new firmware to support this? We should put our thoughts together for a question I can pose to Scott. Daniel ----- Original Message ----- From: "scottmsavage" <sms...@ho...> To: <oo...@ya...> Sent: Thursday, 29 April 2004 21:40 Subject: [oopic] Re: Oopic compiler issues - The low down. > > There are other limitations ...such as no ability to delete > > objects and replace them with new ones as the need arises. > > You will be able to reuse object memory in the new GUI IDE. Not > create and destroy objects mind you, but you will be able to change > the object configuration from one configuration to another > configuration. > > -Scott Savage |
|
From: D. D. M. <dd...@mc...> - 2004-05-06 01:12:49
|
You might each want to take your local snapshot of the page Scott has provided, in case this is a temporary URL. This confirms that my analysis I posted last week--using this will be much more convient than hard thinking for the byte-code reverse engineering. I'll now concentrate on the objects and the byte-code emitted as a result of script syntax examples. Also, I've requested the Access database, but it may not be much more than what was posted on the OOpic list a week or so ago (that link was http://www.oopic.com/ObjectPropListo.html). Daniel ----- Original Message ----- From: "Scott Savage" <sms...@ho...> To: <dd...@mc...> Sent: Wednesday, 05 May 2004 13:18 Subject: RE: OFFLIST: Request for compiler information WAS: [oopic] Re: Oopic compiler issues - The low down. > I only check this email ever so often. > > Here is item 1 on your list. > http://www.oopic.com/OOPicObjectCommandList.html > > As for Item2, do you have Access 2k? If so I can send you item #2. > > -Scott Savage > > > >From: "D. Daniel McGlothin" <dd...@mc...> > >To: <sms...@ho...> > >CC: "D. Daniel McGlothin" <dd...@mc...> > >Subject: OFFLIST: Request for compiler information WAS: [oopic] Re: > >Oopic compiler issues - The low down. > >Date: Thu, 29 Apr 2004 02:25:38 -0400 > > > >Scott, > > > >You said: > > > >"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." > > > >and a bit later: > > > >"No NDA necessary. I have been thinking about releasing the native > >language for some time." > > > > > >I thank you for your generous offer. > > > >On behalf of the group (https://sourceforge.net/projects/oopic-compiler), > >would you provide: > > > >1. native code instructions > >2. object definitions, with OOpic firmware levels each of supported at > >3. permission to package the OOPicMK.exe with the project (versions 3, 4, > >and 5) > >4. catalog of error messages generated by OOPicMK.exe > >5. algorithm or source for OOpicMK.exe > >6. permission to package corrections to the OOpic documentation, or > >alternatively, provide an electronic means of allowing us to send revisions > >of the same to you for psoting at www.oopic.com. > >7. any lists of bugs/annoyances/things-to-do for the OOpic toolchain that > >might be addressed in toolchain revisions. We are aware of Dennis Clark's > >buglist. > >8. list of deprecated and un-implemented objects > >9. a comment on your take as to whether the failure of the shift operation > >(Basic syntax << and >>) is a IDE, compiler, or a firmware issue. > >10. a comment on your take as to whether the problems with array elements > >beyond 4 or 5 is solely a compiler issue. > > > > > >I understand if you wish to keep any of the above 'under wraps' for > >whatever > >reason. Further, I'm aware that some of this information is included at > >www.oopic.com and in the released IDE, but if it is available in a more > >concise form, it would be appreciated. > > > >If you are aware of significant overlap of any effort between yourself and > >this project, perhaps we could assist you rather than working at > >cross-purposes. Please let me know if this is the case. > > > >Finally, congradulations on the Microchip arrangement, as well as the > >SpeakJet; and thanks for the peek at the visual virtual circuit editor you > >recently posted. > > > >Best regards, > >Daniel McGlothin > > > > > >PS, Understanding your position on e-mail, I'll post this by paper mail to > >the address listed at www.oopic.com if I do not get a reply of receipt > >within a couple of days. > > > > > > > > _________________________________________________________________ > Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! > http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/ direct/01/ > > > |
|
From: D. D. M. <dd...@mc...> - 2004-05-06 01:11:43
|
The more I think about Dan Sandberg's idea, I like it.
The notation of 'background' as an attribute of the routine is essentially
what I was thinking of with my Delphi unit 'sections' approach.
Daniel
----- Original Message -----
From: "scottmsavage" <sms...@ho...>
To: <oo...@ya...>
Sent: Friday, 30 April 2004 10:55
Subject: [oopic] Re: Oopic compiler issues - The low down.
> --- In oo...@ya..., Dan Sandberg <x@c...> wrote:
> > With the THEORETICAL syntax I was mentioning earlier,
> > combined with the kinda of objects that the OOPic
> > already supports, we could do something like this:
> > background void activateSolenoid() {
> > if ( button.pressed ) {
> > solenoid = true;
> > solenoidTimer = 5;
> > solenoidTimer.operate = true;
> > }
> > }
> > background void deactiveateSolenoid() {
> > if ( solenoidTimer.operate and solenoidTimer == 0 ) {
> > solenoid = false;
> > solenoidTimer.operate = false;
> > }
> > }
>
> Yes, I like it and it is really COOL! But it is not the way the
> OOPic works. Give me some time and maybe I will be able to figure
> out how to incorporate it.
>
> > Perhaps the root of my confusion is that I don't understand
> > why the code on the OOPic must be so slow.
>
> I am confused. How did you miss it? Read this page of the manual:
> http://www.oopic.com/pgchap14.htm
>
> > The OOPic is the only microcontroller I've ever used, so perhaps
> > I am missing something fundamental.
>
> Sounds to me like it is just that you want the OOPic to be something
> it is not. I think your wish list is a cool idea, but I do not
> think that there is anything on the market right now that works that
> way.
>
> Give me some time and I may be able to change that.
>
> -Scott Savage
>
|
|
From: D. D. M. <dd...@mc...> - 2004-05-06 00:56:09
|
Neil, > One question that arises from this - are we intending to allow out compiler > to work as a drop-in replacement for the existing compiler, ie so that it > works from the existing IDE. If so, then the installer will have to locate > the currently-installed compiler, rename it, and replace it with the new > one. Perhaps, since the IDE is open, we could patch the IDE to allow compiler selection. No need really to lock the user into our preferred product. <smile> Best Regards, Daniel ----- Original Message ----- From: "Neil Durant" <nd...@us...> To: "OOPic Compiler List" <oop...@li...> Sent: Wednesday, 05 May 2004 19:46 Subject: Re: [Oopic-compiler-devel] Summary > Good questions! > > D. Daniel McGlothin wrote: > > A new category: > > Is the tool to support all firmware revisions of the OOpic? > > I say definitely - aim for the most recent firmware revision, and then we > just disable features that aren't present in lower OOPic versions. Unless > the compiler has bizarre workarounds for quirks in each OOPic version? > > > A new category: > > Testing is going to be done how? What is the testing methodology, etc? Do > > any of us have a suit of OOpic in the tools supported firmware revisions? > > If not, are we going to ask Scott Savage for a few freebies? > > We can probably test the bulk of our work by simply comparing the generated > op-codes with those from Scott's compiler, using 'equivalent' code. This > will be especially useful for testing object support, which I guess won't > be changing much from the existing compiler, beyond maybe giving errors > when someone tries to access vapourware. Plus, I don't think testing > against actual sonars, motors, compasses etc is going to be practical! > > However I guess that'll only work so far, and we'll need to do testing > against real hardware for some stuff. I have an OOPic II+ (b.2.2+) and an > OOPic II (b.1.0). > > Perhaps for the various bits of hardware we don't have, we could recruit > a couple of beta testers from the OOPic forum who have the required > itarget hardware. > > Same applies for different development systems - for example for the > Windows compiler we're going to have to test on Win95/98/ME/NT/2000/XP. > > Of course, as it's open source, I guess it's reasonable to release it > having tested it on the hardware we have, and list the hardware it's been > seen to work on. Then people can test it on their own hardware and report > back, in the true spirit of open source knowledge sharing! > > I think we'll be lucky if Scott gives us some freebies! > > > A new category: > > Installer issues have been recently discussed on the OOpic list. What > > 'installer' issues will this project need to address? > > Well, I think the installer issue has come up because of the IDE's > dependency on VB runtime files, which may/may not be present on a given > system, and may not be the correct version. > > I'm hoping that our compiler will be pretty self-sufficient, not relying on > installed DLLs or libraries, and so it should be a simple operation of > putting the compiler exe somewhere on the path. If the compiler depends on > Windows DLLs etc, then we will have lost cross-platform compatibility as > there are no equivalents to the various Windows DLLs on DOS, Linux and > MacOS. I think considering the target audience, it would be acceptable to > make a static build with any libraries compiled in. > > I should be able to "find" a copy of InstallShield for creating a proper > installer for Window. For DOS, I guess we can get away with a batch file > or similar. And for Linux I think it would be acceptable to ship it as a > source code .tar.gz file with compilation instructions (this is widely > regarded as reasonable on Linux). Alternatively it wouldn't be hard to > create ready-compiled RPM or DEB files for Linux. > > One question that arises from this - are we intending to allow out compiler > to work as a drop-in replacement for the existing compiler, ie so that it > works from the existing IDE. If so, then the installer will have to locate > the currently-installed compiler, rename it, and replace it with the new > one. > > Neil > -- > Neil Durant > <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-05 23:47:09
|
Good questions! D. Daniel McGlothin wrote: > A new category: > Is the tool to support all firmware revisions of the OOpic? I say definitely - aim for the most recent firmware revision, and then we just disable features that aren't present in lower OOPic versions. Unless the compiler has bizarre workarounds for quirks in each OOPic version? > A new category: > Testing is going to be done how? What is the testing methodology, etc? Do > any of us have a suit of OOpic in the tools supported firmware revisions? > If not, are we going to ask Scott Savage for a few freebies? We can probably test the bulk of our work by simply comparing the generated op-codes with those from Scott's compiler, using 'equivalent' code. This will be especially useful for testing object support, which I guess won't be changing much from the existing compiler, beyond maybe giving errors when someone tries to access vapourware. Plus, I don't think testing against actual sonars, motors, compasses etc is going to be practical! However I guess that'll only work so far, and we'll need to do testing against real hardware for some stuff. I have an OOPic II+ (b.2.2+) and an OOPic II (b.1.0). Perhaps for the various bits of hardware we don't have, we could recruit a couple of beta testers from the OOPic forum who have the required itarget hardware. Same applies for different development systems - for example for the Windows compiler we're going to have to test on Win95/98/ME/NT/2000/XP. Of course, as it's open source, I guess it's reasonable to release it having tested it on the hardware we have, and list the hardware it's been seen to work on. Then people can test it on their own hardware and report back, in the true spirit of open source knowledge sharing! I think we'll be lucky if Scott gives us some freebies! > A new category: > Installer issues have been recently discussed on the OOpic list. What > 'installer' issues will this project need to address? Well, I think the installer issue has come up because of the IDE's dependency on VB runtime files, which may/may not be present on a given system, and may not be the correct version. I'm hoping that our compiler will be pretty self-sufficient, not relying on installed DLLs or libraries, and so it should be a simple operation of putting the compiler exe somewhere on the path. If the compiler depends on Windows DLLs etc, then we will have lost cross-platform compatibility as there are no equivalents to the various Windows DLLs on DOS, Linux and MacOS. I think considering the target audience, it would be acceptable to make a static build with any libraries compiled in. I should be able to "find" a copy of InstallShield for creating a proper installer for Window. For DOS, I guess we can get away with a batch file or similar. And for Linux I think it would be acceptable to ship it as a source code .tar.gz file with compilation instructions (this is widely regarded as reasonable on Linux). Alternatively it wouldn't be hard to create ready-compiled RPM or DEB files for Linux. One question that arises from this - are we intending to allow out compiler to work as a drop-in replacement for the existing compiler, ie so that it works from the existing IDE. If so, then the installer will have to locate the currently-installed compiler, rename it, and replace it with the new one. Neil -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-05-05 22:51:56
|
Neil, A new category: Is the tool to support all firmware revisions of the OOpic? A new category: Testing is going to be done how? What is the testing methodology, etc? Do any of us have a suit of OOpic in the tools supported firmware revisions? If not, are we going to ask Scott Savage for a few freebies? A new category: Installer issues have been recently discussed on the OOpic list. What 'installer' issues will this project need to address? Best Regards, Daniel PS. For the record, I have one unused OOpicR. ----- Original Message ----- From: "Neil Durant" <nd...@us...> To: "OOPic Compiler List" <oop...@li...> Sent: Wednesday, 05 May 2004 09:26 Subject: [Oopic-compiler-devel] Summary > I went through our longish thread of ideas and question asking and have > come up with a summary of what we discussed, just so we know where we are: > > * What level of C language support are we aiming for? > We all pretty much agreed to implement C as completely as we can within > the constraints of the OOPic, so aiming for K&R/ANSI where possible but > foregoing things like floating point support. > > * What other languages do we want to support? > It seems we're all in favour of C as the primary language to support, but > BASIC seems to be the more popular amongst the community. So > implementing both looks like the best bet, with Java syntax as a > runner-up. > > * Do we want a mode that allows "standard" OOPic BASIC/C/JAVA to be compiled? > I think we all agreed that some kind of preprocessor to do the conversion > would be the easiest, converting 'legacy' OOPic script syntax to our new > improved syntax. > > * What platforms do we want to support? > General concensus was DOS, Windows, Linux, and maybe Mac. We should aim > to use libraries available on all these platforms to try and maintain a > single codebase for all the platforms. > > * What implementation language(s) do we want to use? > We all agreed on C. > > * Should we use a compiler compiler, such as flex/bison/lex/yacc ? > Looks like we're all in favour of this, as it will save development time > and make adding/changing the supported syntax easier. > > * What extra features do we want to support? > We came up with: > Inline functions > Word / byte / bit arrays in EEPROM via direct references rather than function calls: > Proper shift operators > Malloc to work in EEPROM, and providing pointer arithmetic, similar to Andy's lib > Libraries of useful scripts and VC stuff > Also need to think about these features: > Differentiate between VC and interpreted code, like Delphi divisions > More object-oriented style for user classes (perhaps) > > * What bugs in the existing languages do we specifically want to address? > We tackle every bug we know of > > * Do we need structures and unions, for example? > Would be nice in the long term > > * Requested feature list > We agreed to publish an intended feature list to the forum once we're confident we can > do stuff, and see what else people want. > > * Are we making a collection of command line tools, or are we considering an IDE? > The general concensus was for command line tools > > 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: Neil D. <nd...@us...> - 2004-05-05 15:06:36
|
D. Daniel McGlothin wrote: > Neil, Andrew, > > I'm posting a copy of this request to Scott Savage by regular mail today. > > I've had offlist communication with Scott (about http://OOPicide.McGlothin.info) > in which he said that he only occasionally monitors e-mail to the hotmail > address he is using on the list. I presumed therefore, that he has it set up so > that all but yahoo groups list mail is filtered. > > Anyway, I've sent this to that email address, and today by postal mail. Great work, and diplomatically put!! :-) I doubt we'll get everything (the source/algorithms bit is pushing it!), but at least he knows what we need and he should be able to give us most of that. It will be interesting to see just how supportive he is, or whether it's just rhetoric on the OOPic forum in an attempt to look amenable... :-) Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-05 13:26:10
|
I went through our longish thread of ideas and question asking and have
come up with a summary of what we discussed, just so we know where we are:
* What level of C language support are we aiming for?
We all pretty much agreed to implement C as completely as we can within
the constraints of the OOPic, so aiming for K&R/ANSI where possible but
foregoing things like floating point support.
* What other languages do we want to support?
It seems we're all in favour of C as the primary language to support, but
BASIC seems to be the more popular amongst the community. So
implementing both looks like the best bet, with Java syntax as a
runner-up.
* Do we want a mode that allows "standard" OOPic BASIC/C/JAVA to be compiled?
I think we all agreed that some kind of preprocessor to do the conversion
would be the easiest, converting 'legacy' OOPic script syntax to our new
improved syntax.
* What platforms do we want to support?
General concensus was DOS, Windows, Linux, and maybe Mac. We should aim
to use libraries available on all these platforms to try and maintain a
single codebase for all the platforms.
* What implementation language(s) do we want to use?
We all agreed on C.
* Should we use a compiler compiler, such as flex/bison/lex/yacc ?
Looks like we're all in favour of this, as it will save development time
and make adding/changing the supported syntax easier.
* What extra features do we want to support?
We came up with:
Inline functions
Word / byte / bit arrays in EEPROM via direct references rather than function calls:
Proper shift operators
Malloc to work in EEPROM, and providing pointer arithmetic, similar to Andy's lib
Libraries of useful scripts and VC stuff
Also need to think about these features:
Differentiate between VC and interpreted code, like Delphi divisions
More object-oriented style for user classes (perhaps)
* What bugs in the existing languages do we specifically want to address?
We tackle every bug we know of
* Do we need structures and unions, for example?
Would be nice in the long term
* Requested feature list
We agreed to publish an intended feature list to the forum once we're confident we can
do stuff, and see what else people want.
* Are we making a collection of command line tools, or are we considering an IDE?
The general concensus was for command line tools
Neil
--
Neil Durant
<nd...@us...>
|
|
From: Neil D. <nd...@us...> - 2004-05-05 13:05:58
|
D. Daniel McGlothin wrote: > I'm going to be delayed on the byte-code reverse engineering by real work for > probably the rest of the week. We don't have any deadlines to meet, and we're all in this as volunteers working in what spare time we have, so it's cool. We work at whatever pace works. > I'll continue the detailed analysis of the BASIC syntax generated byte-code, > then do spot comparisons to the C and Java syntax byte-codes. I'm assuming that > I'll find that all syntax choices generate equivalent byte-code for equivalent > script structures. Sounds good. There aren't any language features in the C/Java syntax that don't appear in the BASIC syntax are there? > Then I'll move onto the object list, and try to infer the meanings of byte-code > related to them. Good work! > You two are going to then do the heavy lifting about syntax selection, code > generation, and so forth. Right? Well I think I speak for Andy as well as myself when I say we were hoping you'd do it all, so we could just kick back with a beer and then take some of the glory when you've finished... :-) Yeah, I think Andy and I are keen to get the heavy lifting code underway, and you can get involved with that as much or as little as you like. > What specifically do you need to know as a result of the byte-code analysis to > support the more arcane aspects of what is required to perform the code > generation? In other words, please give me some guidance as to the right > questions to ask of the byte-code. There are probably many questions we need to ask of the byte code. However, some that I can think of: 1. How is RAM allocated when variables/objects declared? Eg does the compiler just increment some pointer to the current free RAM and allocate there? 2. What is the general structure in byte code for each of the main syntactical structures? For example when you compile a for loop, what byte codes are generated to implement that structure? We need to determine this for a generic loop, independent of its context. And the same for if, while, switch, functions, etc etc. I guess we essentially need a generic 'template' of byte codes, in which we can plug in the context-specific bits such as addresses of the variables involved etc. 3. How are expressions handled? Are they just converted from infix format to postfix (ie reverse polish) or is anything else involved? That's all I can think of right now. I think number 2 is the biggie! Neil -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-05-05 12:24:43
|
I'm going to be delayed on the byte-code reverse engineering by real work for probably the rest of the week. I'll continue the detailed analysis of the BASIC syntax generated byte-code, then do spot comparisons to the C and Java syntax byte-codes. I'm assuming that I'll find that all syntax choices generate equivalent byte-code for equivalent script structures. Then I'll move onto the object list, and try to infer the meanings of byte-code related to them. You two are going to then do the heavy lifting about syntax selection, code generation, and so forth. Right? What specifically do you need to know as a result of the byte-code analysis to support the more arcane aspects of what is required to perform the code generation? In other words, please give me some guidance as to the right questions to ask of the byte-code. Best Regards, Daniel |
