oopic-compiler-devel Mailing List for OOPic Compiler (Page 4)
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: D. D. M. <dd...@mc...> - 2004-05-05 12:03:02
|
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. Best regards, Daniel -----Original Message----- From: D. Daniel McGlothin [mailto:dd...@mc...] Sent: Thursday, April 29, 2004 2:18 AM To: sms...@ho... Cc: D. Daniel McGlothin Subject: OFFLIST: Request for compiler information WAS: [oopic] Re: Oopic compiler issues - The low down. 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. 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. |
|
From: Neil D. <nd...@us...> - 2004-05-04 23:12:09
|
D. Daniel McGlothin wrote: > 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? Odd - I replied to this last week but my e-mail never made it to the list. I've also had a few other similar incidents with non mailing list e-mail. Investigating! Anyway, my response was, yes go ahead and see what you can get out of Scott. I think after some of my postings to the OOPic group you might be a better bet! :-) Neil -- Neil Durant <nd...@us...> |
|
From: Neil D. <nd...@us...> - 2004-05-01 14:22:54
|
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...> |
|
From: Andrew P. <wa...@ic...> - 2004-04-30 20:27:46
|
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 |
|
From: D. D. M. <dd...@mc...> - 2004-04-30 19:17:41
|
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 > > > |
|
From: Neil D. <nd...@us...> - 2004-04-30 13:34:17
|
D. Daniel McGlothin wrote: > OK, code jockeys, > > I thought this was an interesting insight. > > Scott says: > > "The OOPic native language is a forth derivate because forth is the > best for functioning in a limited memory space." Indeed - although given that you'd already determined it was a stack-based interpreted, I was kind of guessing it would be Forth-like. Which means we could create a Forth-like language that maps almost directly onto the op-codes, to give us extra low-level control, perhaps! Neil -- Neil Durant <nd...@us...> |
|
From: D. D. M. <dd...@mc...> - 2004-04-30 12:45:31
|
OK, code jockeys, I thought this was an interesting insight. Scott says: "The OOPic native language is a forth derivate because forth is the best for functioning in a limited memory space." Best regards, Daniel -----Original Message----- From: scottmsavage [mailto:sms...@ho...] Sent: Thursday, April 29, 2004 11:48 PM To: oo...@ya... Subject: [oopic] Re: Real programmers don't use VCs --- In oo...@ya..., "Mark Mullen" <mjmullen@b...> wrote: > Now that is a loaded subject line ;-) I would have to add that > real programmers don't write in higher level languages LOL Ok, now that the subject has been brought up My take on it is that real programmers can program in any language because they can discern which language is useful for which project. There is a definite philosophical mind set behind each language and to capture the imagination of the creators of such languages is a revelation that has gone unequaled in any other experience that I have had. The OOPic firmware is 100% assembly because a language such as C or Basic could not even come close to what it takes to do such a thing. Sorry to burst anyone's bubble. The OOPic compiler is 100% Visual Basic because it is the simplest high level language around these days. The OOPic native language is a forth derivate because forth is the best for functioning in a limited memory space. The OOPic applications are Object based Virtual Circuits because I thought that would be a really cool concept to work with. For those of you who purport your aversion for any particular language, just ask yourself what you would think of a carpenter that showed up to a job with only Philips head or only slotted head screwdrivers? What would you think of a programmer that did the same? |
|
From: D. D. M. <dd...@mc...> - 2004-04-30 12:45:31
|
Hey, moderator, untie me, please.
Daniel
-----Original Message-----
From: oop...@li...
[mailto:oop...@li...]
Sent: Friday, April 30, 2004 8:10 AM
To: dd...@mc...
Subject: Your message to Oopic-compiler-devel awaits moderator approval
Your mail to 'Oopic-compiler-devel' with the subject
Re: [Oopic-compiler-devel] Reverse-engineering the OOpicMK
compiler--preliminary
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message body is too big: 172403 bytes but there's a limit of 40 KB
Either the message will get posted to the list, or you will receive
notification of the moderator's decision.
|
|
From: D. D. M. <dd...@mc...> - 2004-04-30 12:08:49
|
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
>
|
|
From: Neil D. <nd...@us...> - 2004-04-30 10:34:46
|
Andrew Porrett wrote: > At 03:29 AM 4/30/2004 +0100, Neil Durant wrote: > >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. > > Yes, we need to take a long, hard look at the .oex files that are uploaded > to the OOPic. This will tell us what sort of useful stuff we can do. For > example, I'm pretty sure that the start of the file has an object list > definition that is used to build the actual objects in RAM. Once the real > objects are in RAM, the list in the EEPROM is ignored. How easy would it > be to have a new object list copied there and then trigger a reset of the > processor - instant change of available objects. Just don't try to access > an object that doesn't exist any more. Obviously, you'd need to branch to > the appropriate object initialization routine right after the reset, etc. > > I need a solid breakdown of everything that can be done in a .oex file to > come up with more goodies. Indeed - there could be all sorts of nifty features we could exploit! Neil -- Neil Durant <nd...@us...> |
|
From: Andrew P. <wa...@ic...> - 2004-04-30 04:22:23
|
At 03:23 AM 4/30/2004 +0100, Neil Durant wrote: >Has anyone suggested implementing malloc to work in EEPROM, and providing >pointer arithmetic? That's sorta what I did with some of my library routines, so I'd assumed we'd do something along those lines. >> 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..." > >Certainly true. Maybe not essential to implement it as a high priority >though. I suspect it's trivial to do. It's all in the language definition, no? >To my knowledge there isn't any one defacto standard BASIC, and so we would >have less incentive to do much to the existing OOPic BASIC support, beyond >fixing the obvious bugs and some other tweaks. So I imagine it wouldn't be >as much work as implementing comprehensive C support. Seems that way. >Fair points! I imagine our overall feature plan is going to look really >ambitious, and will either spark enthusiasm or cries of, "You'll never >manage it!". Yes, most OOPicers would see this project as a mammoth task, but it ain't. > But it should also get people commenting on our ideas and >maybe suggesting stuff we hadn't considered. However I bet most people >will just glaze over because it's mostly C stuff.... No reason why neat features (like malloc, whatever) can't be provided to BASIC users. I would expect them to have access to most of it (do we give BASIC #include and #define equivalents?) > [my OOP suggestion snipped for brevity] > >> I think that it's not C anymore, but I don't have a huge problem with that. > >But then neither is oUserClass (or any of the OOPic object for that >matter!). The idea is to make the current oUserClass functionality a bit >more like an existing standard OOP language, and to allow the created >objects to have a type, rather than all user classes being of type >oUserClass regardless of what user class they actually are! Understood. >> My immediate thoughts are: >> - where does this thing get constructed? RAM? EEPROM? > >Exactly the same as existing oUserClass variables, which is presumably RAM. OK. >> - when does it get constructed? If it's only at program startup, the "new" >> seems like a fib. > >It's no more of a fib than the existing 'new' when creating OOPic objects. Which is a big fib. >Were you thinking about removing 'new' and making OOPic object creation >look more like global statics? That's what I did with my preprocessor. I'd vote for making "new" optional, cuz it's a big fib. >> - can this thing get deleted? > >I hadn't really thought they should be, just as oUserClass objects can't >be. It might be nice if they could, from a memory saving point of view, >but I imagine in most OOPic projects you'd end up creating these things and >keeping them there for the lifetime of the program. If new objects can't be created at runtime to reuse the space freed up by a deleted object, then there's no point in deleting objects, so that makes them static, so what's with this "new" keyword... :) >> - is there a significant advantage to this approach, or is it just >> something that appeals to a OOP guy? > >Advantages I can think of: > >1) Familiarity to C++/Java guys > >2) Ability to define multiple classes in a single file, as the classes have > their own typenames (like C structs) which would be handy for class > libraries > >3) Ability to declare class objects by name rather than path/filename. > Just #include your class library and then start defining objects with the > various class types. > >4) Potentially the ability to copy classes. You can copy structs, so why > not classes? > >5) Clarity - as user classes stand, a typical program may have several > main() functions, in different files, and the main() of each user class > is called implicitly. OK, I get it. >> Some real world examples would help me here... > >Think of it as an oUserClass with language closer to C/C++. oUserClass >isn't even a proper VC object - it's merely a logical source construct. My >proposal is to make it look more like a C++ construct (which semantically >it already is, as oUserClass, but it's declared and created in its own >quirky way). The C-like aspect is that you could treat the created object >like a struct, which would have a type. The C++-like aspect is that these >objects can have methods, as can oUserClasses. The only additional feature >I suggested was replacing main() with something like constructor() for >clarity and to distinguish of from the 'true' main(), and allowing >arguments to be passed in to specify the object's initial state. > >If I want to *really* put my OOP hat on, I'd add that we could also create >new classes by inheriting from others... :-) > >Examples would be basically any oUserClass example, but in language terms I >think it would be cleaner. I hear ya. ...Andy |
|
From: Andrew P. <wa...@ic...> - 2004-04-30 03:15:32
|
At 03:29 AM 4/30/2004 +0100, Neil Durant wrote: >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. Yes, we need to take a long, hard look at the .oex files that are uploaded to the OOPic. This will tell us what sort of useful stuff we can do. For example, I'm pretty sure that the start of the file has an object list definition that is used to build the actual objects in RAM. Once the real objects are in RAM, the list in the EEPROM is ignored. How easy would it be to have a new object list copied there and then trigger a reset of the processor - instant change of available objects. Just don't try to access an object that doesn't exist any more. Obviously, you'd need to branch to the appropriate object initialization routine right after the reset, etc. I need a solid breakdown of everything that can be done in a .oex file to come up with more goodies. ...Andy |
|
From: Neil D. <nd...@us...> - 2004-04-30 03:12:23
|
Andrew Porrett wrote: > 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???) Fielding the flood of e-mails!!! :-) I'm not working tomorrow, so it's cool.... Neil -- Neil Durant <nd...@us...> |
|
From: Andrew P. <wa...@ic...> - 2004-04-30 02:55:59
|
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 |
|
From: Andrew P. <wa...@ic...> - 2004-04-30 02:37:49
|
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 |
|
From: Neil D. <nd...@us...> - 2004-04-30 02:35:48
|
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...> |
|
From: Neil D. <nd...@us...> - 2004-04-30 02:29:16
|
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...> |
|
From: Neil D. <nd...@us...> - 2004-04-30 02:23:28
|
Andrew Porrett 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. Fair point. Has anyone suggested implementing malloc to work in EEPROM, and providing pointer arithmetic? > >> 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..." Certainly true. Maybe not essential to implement it as a high priority though. > 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, ...) To my knowledge there isn't any one defacto standard BASIC, and so we would have less incentive to do much to the existing OOPic BASIC support, beyond fixing the obvious bugs and some other tweaks. So I imagine it wouldn't be as much work as implementing comprehensive C support. > >> 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. Fair points! I imagine our overall feature plan is going to look really ambitious, and will either spark enthusiasm or cries of, "You'll never manage it!". But it should also get people commenting on our ideas and maybe suggesting stuff we hadn't considered. However I bet most people will just glaze over because it's mostly C stuff.... Speaking of a feature plan, maybe we should actually start making one, just as a plain text file, and add it to the Sourceforge page as documentation. I guess we need to read up on how to do updates to files and give ourselves modify rights etc. Sourceforge is set up to use CVS for version control for source and docs. Have either of you use CVS much/at all? [my OOP suggestion snipped for brevity] > I think that it's not C anymore, but I don't have a huge problem with that. But then neither is oUserClass (or any of the OOPic object for that matter!). The idea is to make the current oUserClass functionality a bit more like an existing standard OOP language, and to allow the created objects to have a type, rather than all user classes being of type oUserClass regardless of what user class they actually are! > My immediate thoughts are: > - where does this thing get constructed? RAM? EEPROM? Exactly the same as existing oUserClass variables, which is presumably RAM. > - when does it get constructed? If it's only at program startup, the "new" > seems like a fib. It's no more of a fib than the existing 'new' when creating OOPic objects. Were you thinking about removing 'new' and making OOPic object creation look more like global statics? > - can this thing get deleted? I hadn't really thought they should be, just as oUserClass objects can't be. It might be nice if they could, from a memory saving point of view, but I imagine in most OOPic projects you'd end up creating these things and keeping them there for the lifetime of the program. > - is there a significant advantage to this approach, or is it just > something that appeals to a OOP guy? Advantages I can think of: 1) Familiarity to C++/Java guys 2) Ability to define multiple classes in a single file, as the classes have their own typenames (like C structs) which would be handy for class libraries 3) Ability to declare class objects by name rather than path/filename. Just #include your class library and then start defining objects with the various class types. 4) Potentially the ability to copy classes. You can copy structs, so why not classes? 5) Clarity - as user classes stand, a typical program may have several main() functions, in different files, and the main() of each user class is called implicitly. > Some real world examples would help me here... Think of it as an oUserClass with language closer to C/C++. oUserClass isn't even a proper VC object - it's merely a logical source construct. My proposal is to make it look more like a C++ construct (which semantically it already is, as oUserClass, but it's declared and created in its own quirky way). The C-like aspect is that you could treat the created object like a struct, which would have a type. The C++-like aspect is that these objects can have methods, as can oUserClasses. The only additional feature I suggested was replacing main() with something like constructor() for clarity and to distinguish of from the 'true' main(), and allowing arguments to be passed in to specify the object's initial state. If I want to *really* put my OOP hat on, I'd add that we could also create new classes by inheriting from others... :-) Examples would be basically any oUserClass example, but in language terms I think it would be cleaner. Neil -- Neil Durant <nd...@us...> |
|
From: Andrew P. <wa...@ic...> - 2004-04-30 02:01:11
|
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 |
|
From: D. D. M. <dd...@mc...> - 2004-04-30 01:47:33
|
> >> 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 |
|
From: D. D. M. <dd...@mc...> - 2004-04-30 01:42:38
|
> >> 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 |
|
From: Andrew P. <wa...@ic...> - 2004-04-30 01:20:20
|
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
|
|
From: Andrew P. <wa...@ic...> - 2004-04-30 01:20:19
|
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 |
|
From: Andrew P. <wa...@ic...> - 2004-04-30 00:38:44
|
At 11:46 PM 4/29/2004 +0100, Neil Durant wrote: >Did you happen to spot the posting from Scott Savage about the object >property list? Yup. >I take it the _###____ stuff describes which bits are involved, and the >A1X, B1X etc describes availability on different target chips. Looks that way. >I'm guessing the first digit in the 0,7, 1.6 etc represents the byte >offset, but any idea what the digit after the '.' is? It appears to >correspond to the highest bit with a '#' in the preceding column. It is the highest bit number (zero = LSB, seven = MSB) used by the property in the byte. Pretty tacky actually. For A2D IOLine, it should be 1.6-4 ...Andy |
|
From: Neil D. <nd...@us...> - 2004-04-29 22:46:10
|
Did you happen to spot the posting from Scott Savage about the object property list? <http://www.oopic.com/ObjectPropListo.html> I take it the _###____ stuff describes which bits are involved, and the A1X, B1X etc describes availability on different target chips. I'm guessing the first digit in the 0,7, 1.6 etc represents the byte offset, but any idea what the digit after the '.' is? It appears to correspond to the highest bit with a '#' in the preceding column. Neil -- Neil Durant <nd...@us...> |
