oopic-compiler-devel

Re: [Oopic-compiler-devel] OOPic Compiler

[Andrew P. <wa...@ic...>]

At 12:57 AM 19/10/2004 +0100, Neil Durant wrote:
>Hiya folks!
>
>Long time no traffic on this list!  Just thought I'd post something to see
>if everyone is still interested in going ahead with this project?

I thought you'd have it done by now!


>After the discussion about using Python as an implementation language for
>the OOPic compiler, I bought a book on Python and have spent the last
>couple of months learning it, and I have to say, it's an ideal language for
>this kind of project.  I kept thinking as I read parts of the book, "That
>would be excellent for writing a parser" or suchlike.  And the
>platform-independent aspect comes for free.
>
>So now, having finished the book, I'm keen to launch into some
>development, and I really think we should use Python!

I don't think I'll be doing my part in Python, but that doesn't mean others
can't do their modules that way.


>Thoughts?  Let's get this project moving!

I've made available my initial efforts at a .oex file disassembler; it's
still fairly rough, but hopefully it will inspire y'all.  It's at:

<http://home.ica.net/~phoenix/wap/OOPic/OEX-VIEW.ZIP>

The .c file is the original OOPic source code and the .txt file is the
disassembler output of the .oex file.  The .xlat file has to be built by
the human in charge...  I'd be interested in knowing how the disassembler
handles your own .oex files.


...Andy

[Oopic-compiler-devel] Emulator

[Neil D. <nd...@us...>]

Following a bit of abortive discussion on the OOPic mailing list about an
OOPic emulator, it strikes me that actually it wouldn't be so hard to do.
We have the spec of the byte code, and it's a relatively simple stack-based
machine.  I guess the hard part would be modelling the VCs, but again, not
all that difficult.

Btw, regarding the OOPic compiler, I'm half way through writing a
preprocessor for it, in Python, and it's fitting together nicely.  I'm
going to get some time over Christmas to work on it, so I should have
something usable to upload by the New Year.  I chose to start on a
preprocessor because (a) it would be useful, and (b) it's a gentle
introduction to Python for me, before embarking on the compiler fully.

Have a good Christmas, guys!

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

Re: [Oopic-compiler-devel] Emulator

[D. D. M. <dd...@mc...>]

Based on the Python discussion earlier, I introduced a work collegue to it,
and he went ahead and wrote a PLC (ladder logic) program
comparison/differences tool.  I still have to write my first "Hello World",
although I have read the manual and think I have the gist of the language.

Once the emulator is written, then why not just compile it directly to
PIC/SX/AVR chips and bypass the oopic altogether?  I suppose that is
probably going a bit father than where we are headed, though.  And if we are
up to that level of effort, wouldn't we be writting directly for the chips
already?

Incidently, have you noticed the recent release of Parallax's SX/B basic
preprocessor for the SX chips?

Daniel


----- Original Message ----- 
From: "Neil Durant" <nd...@us...>
To: <oop...@li...>
Sent: Thursday, 16 December 2004 19:56
Subject: [Oopic-compiler-devel] Emulator


> Following a bit of abortive discussion on the OOPic mailing list about an
> OOPic emulator, it strikes me that actually it wouldn't be so hard to do.
> We have the spec of the byte code, and it's a relatively simple
stack-based
> machine.  I guess the hard part would be modelling the VCs, but again, not
> all that difficult.
>
> Btw, regarding the OOPic compiler, I'm half way through writing a
> preprocessor for it, in Python, and it's fitting together nicely.  I'm
> going to get some time over Christmas to work on it, so I should have
> something usable to upload by the New Year.  I chose to start on a
> preprocessor because (a) it would be useful, and (b) it's a gentle
> introduction to Python for me, before embarking on the compiler fully.
>
> Have a good Christmas, guys!
>
> Neil
> -- 
> Neil Durant
> <nd...@us...>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Oopic-compiler-devel mailing list
> Oop...@li...
> https://lists.sourceforge.net/lists/listinfo/oopic-compiler-devel

Re: [Oopic-compiler-devel] Emulator

[Neil D. <nd...@us...>]

D. Daniel McGlothin wrote:
> Based on the Python discussion earlier, I introduced a work collegue to it,
> and he went ahead and wrote a PLC (ladder logic) program
> comparison/differences tool.  I still have to write my first "Hello World",
> although I have read the manual and think I have the gist of the language.

I find that once you "dig in", with the manual within easy reach, it's
fairly easy to be productive with Python.  I've found that it's also
exceptionally well suited to what we're doing, at least the text
lexing/parsing side of things. The amount of code I've written so far for
the preprocessor would have taken several times more code if written in C,
and all the string handling would have been painful in comparison!  Symbol
table?  Piece of cake!  No need to implement a hash table or anything.

And it looks like it will be extremely good at handling the complex data
structures (trees etc) in the core of the compiler.  Incidentally, I've
been reading a book about the assembly code generation aspect of compiler
design, and it's truly fascinating and far deeper than I had imagined.  I
suspect there will be lots of scope for interesting optimisations with that
aspect on the OOPic compiler.

Furthermore I've been thining about the linker side of things, and I don't
think that will be too hard to do, once we clarify the required memory
organisation of an OOPic program image.  I'm really excited about getting
this project underway (half for the satisfaction of writing a fairly
complex piece of open source software, and half for the practical aspect of
making the OOPic more usable!).  It's just a matter of available free time!

> Once the emulator is written, then why not just compile it directly to
> PIC/SX/AVR chips and bypass the oopic altogether?  I suppose that is
> probably going a bit father than where we are headed, though.  And if we are
> up to that level of effort, wouldn't we be writting directly for the chips
> already?

I guess the tricky part is making the microcontroller actually run the code
fast enough.  It's not too difficult to make a multi-gigahertz desktop
machine act like a little microcontroller, but actually performing those
calculations on a little chip is another matter!  Still, worth
investigating if we ever reach that stage and have the inclination!

> Incidently, have you noticed the recent release of Parallax's SX/B basic
> preprocessor for the SX chips?

No, but I have now!  Looks like interesting technology!

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

Re: [Oopic-compiler-devel] Emulator

[Andrew P. <wa...@ic...>]

At 12:56 AM 17/12/2004 +0000, Neil Durant wrote:
>Following a bit of abortive discussion on the OOPic mailing list about an
>OOPic emulator, it strikes me that actually it wouldn't be so hard to do.
>We have the spec of the byte code, and it's a relatively simple stack-based
>machine.  I guess the hard part would be modelling the VCs, but again, not
>all that difficult.

A useful emulator has to handle real world programs - large, complicated
ones.  Those programs need lots of simulated inputs that mimic what will be
seen in real life.  I see that as a problem area.

Also, a simulator that doesn't mimic all the OOPic's bugs (like the broken
LCD handling) will make the user's life miserable.


...Andy