Thread: Re: [Oopic-compiler-devel] Re: Asking the community... WAS: Re: [Oopic-compiler-devel] Testing... (Page 2)
Status: Planning
Brought to you by:
ndurant
Menu
▾
▴
oopic-compiler-devel
|
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 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 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: 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 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: 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: D. D. M. <dd...@mc...> - 2004-04-29 02:46:30
|
This portion of everyone has received it. Daniel ----- Original Message ----- From: "Neil Durant" <nd...@us...> To: <oop...@li...> Sent: Wednesday, 28 April 2004 21:51 Subject: [Oopic-compiler-devel] Testing... > Just a quick test message to the new mailing list to see if it works > properly! Is everyone receiving this? > > Neil > -- > Neil Durant > <nd...@us...> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Oopic-compiler-devel mailing list > Oop...@li... > https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel > > |
|
From: D. D. M. <dd...@mc...> - 2004-04-29 03:04:08
|
Neil, Have you yet made a formal and specific request for Scott Savage's assistence for this project, based on his following? <quote> If you guys want to put together a full blown C language compiler, you will have my full support. No need to reverse engineer the compiler. Just ask for whatever you need. I will release the native code instructions and the Object definitions for your developer's group. </quote> If no, do you want me to? Daniel |
|
From: Neil D. <nd...@us...> - 2004-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...> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X