cup-language-devel — For the development of the Cup Programming Language

[Cup-Dev] Status Update

[Keith A. J. <kja...@AG...>]

Well, it's been over a year since the last Cup release, version 0.0.13.
Sadly, I can't say this is an announcement of a release for version
0.1.0. However, a lot of progress is being made in that direction. The
compiler is getting more solid, and the VM is starting to take form now.
Scopes, the stack, value references, all things that are working to some
degree. Today for the first time I compiled and ran a Hello, world
program with version 0.1.0. There was no output as builtin functions are
not working yet, however it includes the stdio.cup and implements the
builtin functions as user-defenced functions that do nothing. I'm
starting to get a bit excited about this, as Cup will be amazing to see.
Watching the compiled bytecode fly by on my screen being executed in
debug mode was quite thrilling.
=20
I've been thinking a lot lately on how to implement builtin functions,
and I'd like it to be pluggible in some form, however, my shared
libraries and pluggable modules and etc skills are not the greatest.
I'll prolly hard code it into cup in a method that could hopefully be
externalized easily later, by someone who is better with such things.
Just using shared libraries I fear may not be realistic, since this is
cross-platform.
=20
Anyway, progress is being made. Some days more than others, but I -WILL-
eventuially release 0.1.0. I'm thinking about getting a pre-release of
0.1.0 when builtin functions are working. The last thing to be
implemented before an official 0.1.0 relerase will probably be complex
data types like lists and dictionaries.
=20
Keith Jackson
=20

[Cup-Dev] Compiler, VM, variables, oh my!

[Keith J. <kja...@ag...>]

Firstly; I made a significant change to the language itself. This is no 
longer correct:

decl x, y = 1, z;

Instead, this is:

var x, y = 1, z;

There has been too much ambiguity with decl used to declare functions and 
variables. While if I dicked with it long enough, I could make it work I'm 
sure, the result wouldn't be pretty in the compiler code, and it really 
isn't gaining anything having the same keyword for two things. I've kinda 
been thinking about this since I first made the choice to use decl for 
variables. It was probably not a wise decision, and made more sense at the 
time, only because it was simpler then.

So, even tho this goes against changing the very basics of the language 
syntax and so on, I think it needed to be done.

Secondly, I've got it implemented, as well as assigning variables. At least 
compiler-side. I've had to add more code to the VM to make it ignore/cope 
with the new opcodes for SET and so on. SET will just pop a value for now, 
as that will keep the stack the correct size.

I think it's getting to the point that some VM stuff needs to be 
implemented. Variables and scoping and so on are mostly done on the compile 
side. Complex data types are the only major thing now missing from the 
compiler, as well as I can tell.

Keith

[Cup-Dev] Functions

[Keith J. <kja...@ag...>]

I've started implementing functions. It's currently in what I'll call a 
'lame' state. If you run:

1;
decl whatever(bleh)
{
   return 7;
}
2;

through the compiler, you'll see it just compiles functions by after the 
PUSH 1, POP, adding a JMP to the PUSH 2, POP, effectively skipping the 
function code. This is Keith being lazy for the time being. In the future 
compiler pass after parse and before compile all the functions will be 
moved to the end, so they are compiled after all the code, then the need 
for the 'jump past the function' code will be removed.

Also, currently it's just compiling the function. There's no symbol table 
for what address it starts at, so the CALL opcode obviously isn't 
implemented. :) THey are compiled, that's all :)

Keith


At 03:30 PM 5/2/2002, Keith Jackson wrote:
>Update of /cvsroot/cup-language/cup/src/compiler
>In directory usw-pr-cvs1:/tmp/cvs-serv3407/compiler
>
>Modified Files:
>         binary.c compiler.h nodes.c parser.y
>Log Message:
>Functions partially implemented
>
>
>
>Index: binary.c
>===================================================================
>RCS file: /cvsroot/cup-language/cup/src/compiler/binary.c,v
>retrieving revision 1.3
>retrieving revision 1.4
>diff -C2 -r1.3 -r1.4
>*** binary.c    2 May 2002 14:16:31 -0000       1.3
>--- binary.c    2 May 2002 19:30:56 -0000       1.4
>***************
>*** 68,71 ****
>--- 68,72 ----
>     unsigned long lstart;
>     CUPCNODE *casenode, *defaultnode;
>+   CUPCNODE *argnode;
>
>     switch (node->op)
>***************
>*** 374,377 ****
>--- 375,411 ----
>         cupc_code_write(comp, CUPOP_JMP);
>         cupc_code_write_data(comp, &cjmp, sizeof(unsigned long));
>+       break;
>+     case CUPCOP_RETURN:
>+       // PUSH arg (optional?)
>+       // RET
>+       if (node->one)
>+         cupc_bin_build(comp, node->one, 0, 0, 0);
>+       cupc_code_write(comp, CUPOP_RET);
>+       break;
>+     case CUPCOP_FUNCTION:
>+       // JMP label1
>+       // ARG blah
>+       // ARG y
>+       // code
>+       // RET
>+       lstart = comp->codelen;
>+       label1 = cupc_code_new_label();
>+       cupc_code_write(comp, CUPOP_JMP);
>+       cupc_code_write_data(comp, &label1, sizeof(unsigned long));
>+       for (argnode = node->two; argnode && argnode->next; argnode = 
>argnode->next)
>+         ;
>+       while (argnode)
>+       {
>+         cupc_code_write(comp, CUPOP_PUSH);
>+         cupc_code_write_data(comp, &comp->datalen, sizeof(unsigned long));
>+         cupc_data_write(comp, CUPDATA_VARIABLE);
>+         cupc_data_write_data(comp, argnode->const_string, 
>strlen(argnode->const_string) + 1);
>+         argnode = argnode->prev;
>+       }
>+       if (node->three)
>+         cupc_bin_build(comp, node->three, 0, 0, 0);
>+       cupc_code_write(comp, CUPOP_RET);
>+       cupc_code_fix_jumps(comp, label1, comp->codelen, lstart);
>+       cupc_code_free_label(label1);
>         break;
>     }
>
>Index: compiler.h
>===================================================================
>RCS file: /cvsroot/cup-language/cup/src/compiler/compiler.h,v
>retrieving revision 1.6
>retrieving revision 1.7
>diff -C2 -r1.6 -r1.7
>*** compiler.h  2 May 2002 14:16:32 -0000       1.6
>--- compiler.h  2 May 2002 19:30:56 -0000       1.7
>***************
>*** 27,32 ****
>     CUPCOP_NOP = 0,
>
>!   CUPCOP_FUNCTION,             // Not implemented
>!   CUPCOP_CALL,                 // Not implemented
>
>     CUPCOP_PUSH_FLOAT,
>--- 27,33 ----
>     CUPCOP_NOP = 0,
>
>!   CUPCOP_FUNCTION,
>!   CUPCOP_CALL,
>!   CUPCOP_RETURN,
>
>     CUPCOP_PUSH_FLOAT,
>
>Index: nodes.c
>===================================================================
>RCS file: /cvsroot/cup-language/cup/src/compiler/nodes.c,v
>retrieving revision 1.4
>retrieving revision 1.5
>diff -C2 -r1.4 -r1.5
>*** nodes.c     2 May 2002 14:16:32 -0000       1.4
>--- nodes.c     2 May 2002 19:30:56 -0000       1.5
>***************
>*** 81,85 ****
>     LIST *list;
>
>!   if (!comp->nodestack || list_length(comp->nodestack) < 1)
>       return NULL;
>
>--- 81,85 ----
>     LIST *list;
>
>!   if (!comp->nodestack)
>       return NULL;
>
>***************
>*** 87,91 ****
>     ret = list_item_pop_front(list);
>     node = ret;
>!   while ((node->next = list_item_pop_front(list)))
>     {
>       node->next->prev = node;
>--- 87,91 ----
>     ret = list_item_pop_front(list);
>     node = ret;
>!   while (node && (node->next = list_item_pop_front(list)))
>     {
>       node->next->prev = node;
>
>Index: parser.y
>===================================================================
>RCS file: /cvsroot/cup-language/cup/src/compiler/parser.y,v
>retrieving revision 1.8
>retrieving revision 1.9
>diff -C2 -r1.8 -r1.9
>*** parser.y    2 May 2002 14:16:32 -0000       1.8
>--- parser.y    2 May 2002 19:30:56 -0000       1.9
>***************
>*** 45,49 ****
>   %type <node> statement lang_block lang_while lang_for lang_continue
>                lang_break expr flt intgr string lang_if lang_switch variable
>!              function funccall
>
>   /* Old
>--- 45,49 ----
>   %type <node> statement lang_block lang_while lang_for lang_continue
>                lang_break expr flt intgr string lang_if lang_switch variable
>!              function funccall lang_return
>
>   /* Old
>***************
>*** 125,128 ****
>--- 125,129 ----
>            | lang_if       { $$ = $1; }
>            | lang_switch   { $$ = $1; }
>+          | lang_return   { $$ = $1; }
>            ;
>
>***************
>*** 165,168 ****
>--- 166,175 ----
>   lang_break: TOKEN_BREAK ';' { $$ = cupc_node_new(CUPCOP_BREAK, NULL, NULL,
>                                                    NULL, NULL); }
>+           ;
>+
>+ lang_return: TOKEN_RETURN ';' { $$ = cupc_node_new(CUPCOP_RETURN, NULL, 
>NULL,
>+                                                    NULL, NULL); }
>+            | TOKEN_RETURN expr ';' { $$ = cupc_node_new(CUPCOP_RETURN, $2,
>+                                                         NULL, NULL, NULL); }
>             ;
>
>
>
>_______________________________________________________________
>
>Have big pipes? SourceForge.net is looking for download mirrors. We supply
>the hardware. You get the recognition. Email Us: ban...@so...

Re: [Cup-Dev] Compiler, Passes and Static Vars.

[Keith J. <ke...@cr...>]

Okay, after looking at the code more, and thinking about implementing
functions into the compiler, I think I'm understanding what you are saying
better. Also, I'm remembering my train of thought when I wrote what's there
now. :)

You're right, it's a one parse pass, one compile pass compiler. Parsing will
catch things like 1 = 2; and missing semicolons and other syntax issues,
however, won't recognize a function call to a function that doesn't exist,
etc.

Furthermore, the compile stage assumes the node tree is correct, and does
not do checks for those sort of errors (undefined functions, no such
variable in scope, etc).

Realizing this, and what you are talking about, I also remembered my
reasoning for this. Currently it parses, then compiles. My original plan was
to add another step in there between the parse and compile that basically
will go thru the node tree and do extensive error checking, scope checking,
etc, etc, etc. Whatever needs to be done. Warnings about stuff like using
'=' in an if instead of '==' and so on. I'm also remembering that I decided
to just ignore that pass for now. Getting the parse pass and the compile
pass working is critical for starting on VM work. Adding that other compiler
pass can be done later, once the compiler handles the Cup language fully,
and VM work is started. In the meantime, we just have to assume the program
isn't making stupid code.

In a way, that's good as well, as the VM has to be able to recover from any
bytecode, so we'll be able to test invalid things like trying to assign a
value to a constant. Or calling a function that doesn't exist, or whatever.

Anyway, sorry I didn't understand before. I'm going to work on implementing
functions now in the compiler.

Keith


On Wed, 1 May 2002, Craig Reagan wrote:

> Ok, in my mind this is still a one pass compiler, the first
> pass is a function of the parser to create a node tree, and
> the second pass is actually what I would consider a compiler
> action.  It's all semantics anyway not really important,
> after considering my earlier thoughts and studying the code
> further, I agree that what we have right now is fine.  If we
> ever decide to implement static vars we may have a problem
> which, I think, can be solved by adding a place holder to
> the function node but what happens when that function goes
> out of scope...Still need to study this some more.
> 
> Craig

[Cup-Dev] Compiler, Passes and Static Vars.

[Craig R. <c-r...@ti...>]

Keith said,
>Well, depends what you consider a pass. I'm still no
compiler expert,
>however, I think technically it's already a two pass
compiler. In one pass,
>we take the source code and compile it into a parse
tree/node structure.
>Then we go through that, and write the actual binary data.

Ok, in my mind this is still a one pass compiler, the first
pass is a function of the parser to create a node tree, and
the second pass is actually what I would consider a compiler
action.  It's all semantics anyway not really important,
after considering my earlier thoughts and studying the code
further, I agree that what we have right now is fine.  If we
ever decide to implement static vars we may have a problem
which, I think, can be solved by adding a place holder to
the function node but what happens when that function goes
out of scope...Still need to study this some more.

Craig

Re: [Cup-Dev] TODO list

[Keith J. <ke...@cr...>]

On Tue, 30 Apr 2002, Craig Reagan wrote:

> Yeah, I figured that one out, I wasn't setting the vm->binary and
> vm->binlen, which is pretty stupid since I was looking at it last night
> wondering how the vm is supposed to find the binary that I had compiled.  Oh
> well, one of those late night things where I was beating myself up instead
> of just going to bed and starting fresh the next day.  I also figured out
> that vm->retval isn't set to anything, and cup_new_value() isn't implemented
> yet.  So I was wondering, what about making the vm->retval a CUPVALUE, but
> not a pointer to one, that way it's always there and there's no need to
> worry about disposing of it when the vm goes away?

Well, we have the CUPVM struct that we have to take care of with
cup_free_vm() anyway. I figure in that function we can clean up the retval.
Order of operations:

Create a VM
Set the binary
Set any global vars
Add function hooks
Execute
re-execute as needed, maybe changing global vars and function pointers
When done, free the vm

So, when we execute, see if there is a previous value, if so, free it, when
the vm is freed, if there's a retval, free it. It should be specified in the
API docs that when the vm is freed, the programmer should not have any
references to the value. This would be true even if it wasn't a pointer,
since the struct is freed along with the vm then. If the programmer using
the api wants to keep the return value after the vm is destroyed or code is
executed again, he or she must make their own copy of it. I've been trying
to keep a very strict structure on what memory is managed by the api, and
what memory is managed by the programmer.


> Anyway just a thought, I think I'm going to try to implement the functions
> that are described by the API that aren't there yet, since those would make
> it much easier to debug anything else added to the VM.

Okie dokie, shoudl be good.

> Some of this stuff
> is kinda difficult because it's the chicken and egg thing, which brings up
> another question.  Where's the compiler supposed to put all the variables
> declared in the program, I haven't gotten a complete grasp of everything in
> the compiler yet but do we need to implement some sort of symbol table?  I
> know the compiler only does one pass right now, but what about doing another
> pass first to create the scopes and vars that go with them, and then the
> second pass to create the code?

Well, depends what you consider a pass. I'm still no compiler expert,
however, I think technically it's already a two pass compiler. In one pass,
we take the source code and compile it into a parse tree/node structure.
Then we go through that, and write the actual binary data. During the
writing, when we encounter constants like x = 7, it will take the 7 and
write it to one area, then it will write the code to another area. It will
look like:

  DATA                         CODE
    7 (4 byte integer)          PUSH x
                                PUSH 0x0001  (address of data in data section)
                                SET

Or something like that. So in a way, a symbol table already exists. The
compiler is pretty smart compared to what it used to be, but, that second
pass could use more work, it needs more smarts recognizing scoping rules and
whatnot. But the basics are there, it just needs to be enhanced.


> 
> Hey, don't let me wear you out with this thing, I just have to throw these
> thoughts out there so I can digest them later.

I know exactly what you mean.

> I do think for now making
> the vm->retval a CUPVALUE would simplify things as far as getting the VM up
> and working.

I don't think so, really. See above.

> 
> Craig
> 
> ----- Original Message -----
> From: "Keith Jackson" <ke...@cr...>
> To: "Cup-Dev List" <cup...@li...>
> Sent: Tuesday, April 30, 2002 10:58 AM
> Subject: Re: [Cup-Dev] TODO list
> 
> 
> > Not sure what problem you are running into, but I don't -think- It's a
> > problem with the Cup libraries. I just broke cup into two seperate
> programs
> > cupc and cupvm and they seem to work as intended, with the proper magic
> > numbers and all. To see how to write your own program that embeds cup, the
> > cup.c cupc.c and cupvm.c files are good places to start, since that's what
> > they do, simply include and use the cup libraries.
> >
> > Keith
> >
> >
> > On Tue, 30 Apr 2002, Craig Reagan wrote:
> >
> > > Yeah, I was looked at this some more last night, figured the best way to
> go
> > > was to create a small program with cup embeded so I could use C's IO to
> look
> > > at what's going on.  The API document is a little dated, nothing major,
> I'm
> > > trying to keep some notes as I go though so I can remember what needs to
> be
> > > updated.  I was still having a few problems, can't figure out why
> > > cup_compile() seems to return a different binary in my program versus
> using
> > > the '-o' option from the cup built from CVS, thus causing the VM to say
> I
> > > have an "incorrect magic".
> > >
> > > I probably won't have much time to look at this the rest of this week
> > > either, but your inputs are helpful, I need to look at the compiler more
> > > closely if anything just to better understand how to use the debug info.
> > >
> > > Later,
> > > Craig
> > >
> > > ----- Original Message -----
> > > From: "Keith Jackson" <ke...@cr...>
> > > To: "Cup-Dev List" <cup...@li...>
> > > Sent: Tuesday, April 30, 2002 8:10 AM
> > > Subject: [Cup-Dev] TODO list
> > >
> > >
> > > > Rather that try and use SourceForge Task tracking/assignment with such
> a
> > > > relatively small project, I've created the doc/TODO file. So, we can
> > > fiddle
> > > > around in there. As I've been going thru the code, trying to figure
> out
> > > what
> > > > I've finished and what I havn't, I started writing it up. There is
> still a
> > > > lot of compiler work before much VM work can be done. I believe the VM
> is
> > > a
> > > > good shell for now, as you said Craig. The compiler has a lot going
> for
> > > it,
> > > > but is still lacking in some major features outlined in the TODO.
> Anyway,
> > > > I'll see what I can do on some of that, or you can, etc. DUnno when
> I'll
> > > > have a lot of time, but I'll see what I can do. :)
> > > >
> > > > Let me know if ya have any questions, of course.
> > > >
> > > >
> > > > Keith
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> 
> 

Re: [Cup-Dev] TODO list

[Craig R. <cr...@wo...>]

Yeah, I figured that one out, I wasn't setting the vm->binary and
vm->binlen, which is pretty stupid since I was looking at it last night
wondering how the vm is supposed to find the binary that I had compiled.  Oh
well, one of those late night things where I was beating myself up instead
of just going to bed and starting fresh the next day.  I also figured out
that vm->retval isn't set to anything, and cup_new_value() isn't implemented
yet.  So I was wondering, what about making the vm->retval a CUPVALUE, but
not a pointer to one, that way it's always there and there's no need to
worry about disposing of it when the vm goes away?

Anyway just a thought, I think I'm going to try to implement the functions
that are described by the API that aren't there yet, since those would make
it much easier to debug anything else added to the VM.  Some of this stuff
is kinda difficult because it's the chicken and egg thing, which brings up
another question.  Where's the compiler supposed to put all the variables
declared in the program, I haven't gotten a complete grasp of everything in
the compiler yet but do we need to implement some sort of symbol table?  I
know the compiler only does one pass right now, but what about doing another
pass first to create the scopes and vars that go with them, and then the
second pass to create the code?

Hey, don't let me wear you out with this thing, I just have to throw these
thoughts out there so I can digest them later.  I do think for now making
the vm->retval a CUPVALUE would simplify things as far as getting the VM up
and working.

Craig

----- Original Message -----
From: "Keith Jackson" <ke...@cr...>
To: "Cup-Dev List" <cup...@li...>
Sent: Tuesday, April 30, 2002 10:58 AM
Subject: Re: [Cup-Dev] TODO list


> Not sure what problem you are running into, but I don't -think- It's a
> problem with the Cup libraries. I just broke cup into two seperate
programs
> cupc and cupvm and they seem to work as intended, with the proper magic
> numbers and all. To see how to write your own program that embeds cup, the
> cup.c cupc.c and cupvm.c files are good places to start, since that's what
> they do, simply include and use the cup libraries.
>
> Keith
>
>
> On Tue, 30 Apr 2002, Craig Reagan wrote:
>
> > Yeah, I was looked at this some more last night, figured the best way to
go
> > was to create a small program with cup embeded so I could use C's IO to
look
> > at what's going on.  The API document is a little dated, nothing major,
I'm
> > trying to keep some notes as I go though so I can remember what needs to
be
> > updated.  I was still having a few problems, can't figure out why
> > cup_compile() seems to return a different binary in my program versus
using
> > the '-o' option from the cup built from CVS, thus causing the VM to say
I
> > have an "incorrect magic".
> >
> > I probably won't have much time to look at this the rest of this week
> > either, but your inputs are helpful, I need to look at the compiler more
> > closely if anything just to better understand how to use the debug info.
> >
> > Later,
> > Craig
> >
> > ----- Original Message -----
> > From: "Keith Jackson" <ke...@cr...>
> > To: "Cup-Dev List" <cup...@li...>
> > Sent: Tuesday, April 30, 2002 8:10 AM
> > Subject: [Cup-Dev] TODO list
> >
> >
> > > Rather that try and use SourceForge Task tracking/assignment with such
a
> > > relatively small project, I've created the doc/TODO file. So, we can
> > fiddle
> > > around in there. As I've been going thru the code, trying to figure
out
> > what
> > > I've finished and what I havn't, I started writing it up. There is
still a
> > > lot of compiler work before much VM work can be done. I believe the VM
is
> > a
> > > good shell for now, as you said Craig. The compiler has a lot going
for
> > it,
> > > but is still lacking in some major features outlined in the TODO.
Anyway,
> > > I'll see what I can do on some of that, or you can, etc. DUnno when
I'll
> > > have a lot of time, but I'll see what I can do. :)
> > >
> > > Let me know if ya have any questions, of course.
> > >
> > >
> > > Keith
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>

Re: [Cup-Dev] TODO list

[Keith J. <ke...@cr...>]

Not sure what problem you are running into, but I don't -think- It's a
problem with the Cup libraries. I just broke cup into two seperate programs
cupc and cupvm and they seem to work as intended, with the proper magic
numbers and all. To see how to write your own program that embeds cup, the
cup.c cupc.c and cupvm.c files are good places to start, since that's what
they do, simply include and use the cup libraries.

Keith


On Tue, 30 Apr 2002, Craig Reagan wrote:

> Yeah, I was looked at this some more last night, figured the best way to go
> was to create a small program with cup embeded so I could use C's IO to look
> at what's going on.  The API document is a little dated, nothing major, I'm
> trying to keep some notes as I go though so I can remember what needs to be
> updated.  I was still having a few problems, can't figure out why
> cup_compile() seems to return a different binary in my program versus using
> the '-o' option from the cup built from CVS, thus causing the VM to say I
> have an "incorrect magic".
> 
> I probably won't have much time to look at this the rest of this week
> either, but your inputs are helpful, I need to look at the compiler more
> closely if anything just to better understand how to use the debug info.
> 
> Later,
> Craig
> 
> ----- Original Message -----
> From: "Keith Jackson" <ke...@cr...>
> To: "Cup-Dev List" <cup...@li...>
> Sent: Tuesday, April 30, 2002 8:10 AM
> Subject: [Cup-Dev] TODO list
> 
> 
> > Rather that try and use SourceForge Task tracking/assignment with such a
> > relatively small project, I've created the doc/TODO file. So, we can
> fiddle
> > around in there. As I've been going thru the code, trying to figure out
> what
> > I've finished and what I havn't, I started writing it up. There is still a
> > lot of compiler work before much VM work can be done. I believe the VM is
> a
> > good shell for now, as you said Craig. The compiler has a lot going for
> it,
> > but is still lacking in some major features outlined in the TODO. Anyway,
> > I'll see what I can do on some of that, or you can, etc. DUnno when I'll
> > have a lot of time, but I'll see what I can do. :)
> >
> > Let me know if ya have any questions, of course.
> >
> >
> > Keith
> >
> >
> >
> 
> 
> 
> 

Re: [Cup-Dev] TODO list

[Craig R. <cr...@wo...>]

Yeah, I was looked at this some more last night, figured the best way to go
was to create a small program with cup embeded so I could use C's IO to look
at what's going on.  The API document is a little dated, nothing major, I'm
trying to keep some notes as I go though so I can remember what needs to be
updated.  I was still having a few problems, can't figure out why
cup_compile() seems to return a different binary in my program versus using
the '-o' option from the cup built from CVS, thus causing the VM to say I
have an "incorrect magic".

I probably won't have much time to look at this the rest of this week
either, but your inputs are helpful, I need to look at the compiler more
closely if anything just to better understand how to use the debug info.

Later,
Craig

----- Original Message -----
From: "Keith Jackson" <ke...@cr...>
To: "Cup-Dev List" <cup...@li...>
Sent: Tuesday, April 30, 2002 8:10 AM
Subject: [Cup-Dev] TODO list


> Rather that try and use SourceForge Task tracking/assignment with such a
> relatively small project, I've created the doc/TODO file. So, we can
fiddle
> around in there. As I've been going thru the code, trying to figure out
what
> I've finished and what I havn't, I started writing it up. There is still a
> lot of compiler work before much VM work can be done. I believe the VM is
a
> good shell for now, as you said Craig. The compiler has a lot going for
it,
> but is still lacking in some major features outlined in the TODO. Anyway,
> I'll see what I can do on some of that, or you can, etc. DUnno when I'll
> have a lot of time, but I'll see what I can do. :)
>
> Let me know if ya have any questions, of course.
>
>
> Keith
>
>
>

[Cup-Dev] TODO list

[Keith J. <ke...@cr...>]

Rather that try and use SourceForge Task tracking/assignment with such a
relatively small project, I've created the doc/TODO file. So, we can fiddle
around in there. As I've been going thru the code, trying to figure out what
I've finished and what I havn't, I started writing it up. There is still a
lot of compiler work before much VM work can be done. I believe the VM is a
good shell for now, as you said Craig. The compiler has a lot going for it,
but is still lacking in some major features outlined in the TODO. Anyway,
I'll see what I can do on some of that, or you can, etc. DUnno when I'll
have a lot of time, but I'll see what I can do. :)

Let me know if ya have any questions, of course.


Keith

RE: [Cup-Dev] Cup, death, and possible rebirth.

[Craig R. <c-r...@ti...>]

Well, You have been busy...This looks much cleaner than
before, course the VM looks to be mostly just a shell but,
unless I'm just a total fool, most of that should be pretty
straight forward.  Got a couple of ideas for some tweaks to
the compiler but I'll save those for later.  So if the
compiler is working then I'll begin playing with some of the
simpler VM functions to get my feet wet and then see where
that leads us.

Thanks, for the updates.

Craig


-----Original Message-----
From: cup...@li...
[mailto:cup...@li...]On
Behalf Of
Keith Jackson
Sent: Monday, April 29, 2002 2:57 PM
To: cup...@li...
Subject: [Cup-Dev] Cup, death, and possible rebirth.


Alright, I've looked into what I got here, and looks like
what I have is
what is in cvs. I re-added the API document, I don't
remember why it was
removed. Oh well. Cup will compile, if you also check out
the cblist root
directory, and compile and install it. The idea was I was
going to start
taking some of these general purpose things I could re-use
in other
projects, and start making a library. That was then. I still
think I'd like
a library, but, I think for now it's just wasted directories
and link-time
confusion. So, I'll be taking the functionality of cblist
and moving it into
the cup common directory.

The compiler from what I see is in great shape,
development-wise, but the VM
needs the majority of the work. Currently Cup is in a state
where it won't
run anything. It's basically rewritten from the ground up,
and incomplete. A
better 'working' version is 0.0.12, however the code sucks.
Sadly, I decided
to re-write it, which, i don't regret. However, combining
that with stopping
work for 4 months while in the middle of a rewrite, I have
some catchup to
do.

Anyway, will write more later.

Keith

[Cup-Dev] Cup, death, and possible rebirth.

[Keith J. <ke...@cr...>]

Alright, I've looked into what I got here, and looks like what I have is
what is in cvs. I re-added the API document, I don't remember why it was
removed. Oh well. Cup will compile, if you also check out the cblist root
directory, and compile and install it. The idea was I was going to start
taking some of these general purpose things I could re-use in other
projects, and start making a library. That was then. I still think I'd like
a library, but, I think for now it's just wasted directories and link-time
confusion. So, I'll be taking the functionality of cblist and moving it into
the cup common directory.

The compiler from what I see is in great shape, development-wise, but the VM
needs the majority of the work. Currently Cup is in a state where it won't
run anything. It's basically rewritten from the ground up, and incomplete. A
better 'working' version is 0.0.12, however the code sucks. Sadly, I decided
to re-write it, which, i don't regret. However, combining that with stopping
work for 4 months while in the middle of a rewrite, I have some catchup to
do.

Anyway, will write more later.

Keith

Re: [Cup-Dev] Back from the Dead :), cblist????

[Keith J. <ke...@cr...>]

Hey Craig!

Been a while. Must say, I didn't expect to hear from you again. ;)
Sometimes I wonder if it's me, all the people who help with my assorted
projects for some time then leave. :) Anyway, no matter. Cup.... Yes, Cup. I
worked on it a while after you left, and then more or less stopped and
havn't touched it in quite a few months now. I too will have to get back
into it. It's hard for me to stay focused on one project. Advantage of this
is I will be able to use this in most of my other projects. Anywho.. I hope
your events were good ones, not bad. I've been out of town this weekend for
my birthday. Went up to Chesepeake Bay for some fishing. Was a blast.
Anyway, that's why the slow response, any other time, I respond to my emails
in usually under an hour, worst case about 12 hours. :)

Now, where is Cup now? Good question. I have to figure that out myself. I'll
look into it tomorrow. I'm not sure if I have stuff I havn't checked into
CVS or what. I know that I was completely redoing things. I apologize for
the frustration there, but Cup was hitting it's design limitations. Like I
said, I'll go over it all tomorrow, check in my latest changes, figure out
what I've done/broken/fixed/added/removed/etc, and write an email to the
list straight away.

I believe I had done nearly all of the new compiler work that Victor was
going to do, since he disappeared as well. At least, a good portion of it. I
was also working on an API spec, and, getting the VM simplified, since the
compiler now compiles to jumps and conditional jumps instead of compiling to
complex WHILE..ENDWHILE bytecode for the VM. Was fun to write. Writing this
email actually getting me a bit excited about it again. :)

Anyway, the cblist library, was a library I was working on (thinking about?
implemented? toyed with? no idea what state it's in) that would basically
provide a way to have a list like the C++ STL list class. Where a value
could be on several lists at once. I.e. the structure doesn't have to have a
->next and ->prev built into it. Again, I'm not sure what state that is in.
Tomorrow I'll get everything in order, and commit things to CVS so Cup will
at least compile. Then write up something on what's been done/need to be
done.

As for getting frustrated with me, I apologize. While I think it was the
right thing to do, I realize I tend to just up and hack away large chunks of
code / core design / etc without warning people. If nothing else, I need to
learn more about CVS branches, I think. When I get ready to do major
rewrites/etc I can make a branch or something. Anyway, if nothing else,
everying in CVS should be undoable.

I'll talk to you later. For now, I need to go tend to my sunburns.

TTYL

Keith






On Sat, 27 Apr 2002, Craig Reagan wrote:

> Keith, did a CVS download and when I ran configure this is what it said:
> 
> [cup@banzai src]$ ./configure
> loading cache ./config.cache
> checking for gcc... gcc
> checking whether the C compiler (gcc  ) works... yes
> checking whether the C compiler (gcc  ) is a cross-compiler... no
> checking whether we are using GNU C... yes
> checking whether gcc accepts -g... yes
> checking whether make sets ${MAKE}... yes
> checking for ar... /usr/bin/ar
> checking for bison... bison -y
> checking for ranlib... ranlib
> checking for a BSD compatible install... /usr/bin/install -c
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/time.h... yes
> checking for time.h... yes
> checking for unistd.h... yes
> checking for main in -lcblist... no
> configure: error: Must have CrimeBucket Productions library 'cblist' to
> continue.
> 
> ummm...well I poked around crimebucket.com and couldn't find anything for
> this...HELP!!! :)
> 
> I must apologize for the no response a few months back, that was really
> inconsiderate of me, it was just really bad timing.  My life has taken
> several twists and turns in the last few months(Would be good subject matter
> if we ever should get together for a few cold ones, but not worth the
> carpel-tunnel here!) , but I am now back from the dead and would like to
> have another go at this.
> 
> Ok, where was I, if I remember correctly I was working on a modification of
> the VM to reduce the amount of dups, I also remember that the dmem was
> kicking my butt.  I must admit I became really frustrated when you
> completely changed the directory structure of Cup while I was in the middle
> that, but I've also never worked on a project of this sort, guess that kind
> of thing goes with the territory. :)
> 
> Can't say I will have a lot of time to spend on Cup right now,( 2
> boys...baseball season...nuff said) but I would like to at least
> re-familiarize myself with Cup so that I could begin to make some small
> contribution.
> 
> Craig
> 
> 
> 
> 

[Cup-Dev] Back from the Dead :), cblist????

[Craig R. <cr...@wo...>]

Keith, did a CVS download and when I ran configure this is what it said:

[cup@banzai src]$ ./configure
loading cache ./config.cache
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether make sets ${MAKE}... yes
checking for ar... /usr/bin/ar
checking for bison... bison -y
checking for ranlib... ranlib
checking for a BSD compatible install... /usr/bin/install -c
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/time.h... yes
checking for time.h... yes
checking for unistd.h... yes
checking for main in -lcblist... no
configure: error: Must have CrimeBucket Productions library 'cblist' to
continue.

ummm...well I poked around crimebucket.com and couldn't find anything for
this...HELP!!! :)

I must apologize for the no response a few months back, that was really
inconsiderate of me, it was just really bad timing.  My life has taken
several twists and turns in the last few months(Would be good subject matter
if we ever should get together for a few cold ones, but not worth the
carpel-tunnel here!) , but I am now back from the dead and would like to
have another go at this.

Ok, where was I, if I remember correctly I was working on a modification of
the VM to reduce the amount of dups, I also remember that the dmem was
kicking my butt.  I must admit I became really frustrated when you
completely changed the directory structure of Cup while I was in the middle
that, but I've also never worked on a project of this sort, guess that kind
of thing goes with the territory. :)

Can't say I will have a lot of time to spend on Cup right now,( 2
boys...baseball season...nuff said) but I would like to at least
re-familiarize myself with Cup so that I could begin to make some small
contribution.

Craig

[Cup-Dev] [cup-language - Open Discussion] RE: Welcome to Open Discussion

[<no...@so...>]

Read and respond to this message at: 
http://sourceforge.net/forum/message.php?msg_id=497022
By: bucket

This board provides a way to interface with the mailing list in a somewhat anonymous
way. Under normal circumstances, communication for this project will happen
via the mailing list, cup...@so...

Keith


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge and visit: 
http://sourceforge.net/forum/monitor.php?forum_id=78401

[Cup-Dev] Version 0.1.0

[Keith J. <kja...@ag...>]

Alright, don't know who all is still out there, who still cares, or 
whatever, but here goes.

I've been lazy, and working. More lazy than working, of course. But, now 
I've begun to put together Version 0.1.0. It is a complete rewrite. I 
thought that was the best way to approach it. Cup in the 0.0.x series had 
some inherent issues, namely, the VM was too smart, and the compiler was 
too dumb.

Before, a for loop would produce byte code that looks weird:

LOOP
...
Blah, blah.
ENDLOOP

Anyway, any good VM, in my opinion, need not know anything but jumps and 
conditional jumps. All loops and so on should be broken down into 
conditional jumps, compares, and so on, by the compiler. The reason this 
wasn't done to begin with, is because of my ashamedly poor understanding of 
compilers. Since then, I've learned a few things, but, I'm as of yet no 
expert. However, Cup now has a compiler that is worth a damn. Thanks to 
Valentin for pointing out the blindingly obvious ideas of parse trees, 
nodes, etc, etc.

Anyway, if you previously worked on Cup, you may notice all kinds of files 
completely deleted, that are arguably usable. Namely, Win32 stuff. For now, 
it's deleted since it's not been tested or tried with the new version 
0.1.0, and it's not ready to be tested. Most likely a lot of this stuff 
will be 'undeleted' and fixed up, but for now, I wanted it out of the way. 
You can't forge new ideas with old clutter around. At least I can't.

Cup is much more 'raw' then it was before. It compiles, and runs, but its 
missing huge important chunks like a working VM. :) Old versions are still 
for download if you need it, and, you can checkout old versions of the 
source if you need, but, I think it's important to put the newer code up in 
CVS.

And so, I hope to finish up some of the last big chunks of Cup that are 
missing, then start work on improving and cleaning it up.

The code should be easier to understand this time, since, truly, it makes 
more sense. It's not all just a hack because I don't know how to write a 
compiler. :)

Keith

[Cup-Dev] Test

[Keith J. <kja...@ag...>]

Test Message. Don't remember address of the list. How sad.

Keith

[Cup-Dev] IRC Server

[Keith A. J. <Ke...@AG...>]

I've put up an IRC server at irc.crimebucket.com port 6667. In there is
a #Cup channel I'll be hanging out in from now on in one of my many
hangout windows. :) If anyone needs anything you ought to be able to
reach me there, in addition I'll add that to the FAQ.
=20
Keith
=20

[Cup-Dev] Suresh Shukla

[Keith A. J. <Ke...@AG...>]

I've added Suresh Shukla to the project. Over the past little while he's
been looking at the source, and interested in helping out. I'm going to
have him work on getting Cup to adhere more strictly to the API as it's
documented, including getting 'args' back into Cup programs, since I
broke that to make the CupAPI work for now. (what to pass to
cup_new_value() for lists (what type 'args' is) and dictionaries has
been unspecified)
=20
Suresh:
=20
What's I'd like you to work on for now is reading the
CupAPI-Proposed.txt document, and then making sure Cup works as laid out
in that document. What comes to mind as the 'big one', is making it so
you can add additional builtin functions via cup_set_globalfunc(). I
will add a bit more to the document about cup_new_value() for how to
handle lists and dictionaries. I assume you are familiar with how lists
and dicts work, at least on a broad level. Please let me know if you
have any problems or need any help. After you've done some work in that
area and are a bit more familiar with working with the code, we'll let
you loose on whatever you'd like to work on, for the most part. :)
=20
Thanks,
=20
Keith
=20
=20

[Cup-Dev] getopt()

[Keith J. <kja...@cr...>]

Well, just tried to make this all compile on Cygwin. Apparently Cygwin 
doesn't have getopt(). Will have to write our own command line parsing 
before next release.

Keith


+==========================+
| Keith Jackson            |
| kja...@cr... |
+==========================+

Jabber: kja...@ja...

ICQ:    5777909                AIM:    KeithJ406
MSN:    kja...@ho...  Yahoo!: kjackson90

[Cup-Dev] Source Code

[Keith J. <kja...@cr...>]

Alright. Finally, Cup is working again. The Compiler and the VM are 
physically separated, and independent of each other. The code is still 
looking quite ugly, and I'll be doing a lot of cleanup and minor 
re-organizing. In addition, the CupAPI-Proposed document still needs work, 
and the code doesn't completely adhere to it yet, but, the big parts of it 
it does.

If you look, the compiler and VM are separate libraries, but they are 
linked together into the main cup binary, using standard, documented API 
calls into the compiler and VM. The Vm and Compiler are now strong 
standalone libraries, and the cup binary is just a user interface to those 
two libraries.

So, I'd like to see the compiler updated soon, Valentin, and Craig, how is 
it going? You were going to look at fixing up the scope stuff, making the 
VM a bit more effecient with scope and stack operations.

I know I've been not really active, but, I'd like to get this thing going 
again. If you guys have any timeframes, that would be great. If it's going 
to be a long long time, I may start on what you both were going to work on. :)

Anyway, the code works again. Hopefully I'll never have non-working code in 
CVS again. That wasn't very good for the project, I think.

Thanks,

   Keith


+==========================+
| Keith Jackson            |
| kja...@cr... |
+==========================+

Jabber: kja...@ja...

ICQ:    5777909                AIM:    KeithJ406
MSN:    kja...@ho...  Yahoo!: kjackson90

[Cup-Dev] Re: Hello ; some queries

[Keith J. <kja...@cr...>]

At 12:29 AM 8/31/2001, you wrote:
>Hello Keith,
>
>I have compiled the examples and executed them. It looks good to me.
>
>I have some questions:

I got some answers. However, I CC'd the mailing list, one, to point out 
this project isn't dead (-wink-, I've been busy...), and so these good 
questions are answered in the archives.

>1> is the Backus-Naur available for the Cup language. It's hectic to decode
>a file.y to find a grammar.

No. I honestly had never thought of doing a BNF format document up, mostly 
since Cup is still changing drastically. It would be changing. We are much 
closer to a final and complete syntax, but, there will probably be more 
additions and minor updates. It shouldn't be hard to get a BNF document 
drawn up from the grammar file, if anyone is interested in doing that, and 
I'm confident the syntax and semantics are 'production-level'.

>    Further, finite-state machine analysis of grammar would be easier[if at
>all it is being done].

I have to ashamedly admit my ignorance, though, rapid learning curve of 
this sort of thing. I'm still not completely sure what you mean by finite 
state machine. I'll touch on this in your 3rd question.


>2> Why C instead of C++ ? any special reasons. [ I am just curious]

Well, when i started Cup, all I wanted was a tiny little scripting language 
to do 1 or 2 things. I taught myself bison grammar, wrote a little 
grammar.y file and started toying with it. Originally, I tried to use bison 
to not compile the code, but to try and run it. Needless to say, it didn't 
get very far. Since Cup somewhat grew out of that original bison input, 
it's always just been C code, and I can't honestly say at any point did I 
say, 'Cup will be done in C'.

If I were to try and justify now why Cup is in C though, I'd list a few 
reasons:

*) Speed. (Blah, we can argue till we're blue in the face that C++ is no 
slower than C, and I'm not up for a flame war on this subject, but the 
truth is, instantiating and destroying classes makes it easy to have 
inefficient code, again, feel free to disagree, but, that's my opinion)

*) Cup itself isn't object oriented. The compiler side is completely 
linear, and I can see no advantage to trying to build C++ classes around 
it. The same mostly goes with the VM side. We are building a non-OOP 
language. There just isn't much I see that could be gained by C++.


Anyway, no one go get any radical ideas, I have no intention of making the 
Cup compiler/VM with C++. :)



>3> why not separate the Compiler from VM. Making a well-defined interface
>design of (Intermediate Language/binary code)
>    would surely help in modifications/upgrades.
>
>Further , what is the current action-plan. What parts are getting modified,
>currently. Any identified-pending job, which I can help.


Yes! Like I said above, due to the way cup has grown and the way it 
started, they've been getting slowly more and more separated. At the 
moment, the code in CVS doesn't compile, because I'm in the middle of doing 
even more separation between the two into physically different libraries. 
The VM is done, the compiler is not, and won't compile cuz it still depends 
on old shared stuff I'm eliminating. I just havn't had time as of late to 
finish this up, but, I will soon. I promise.

In the meantime, once that is done, Valentin is working on re-writing the 
compiler more or less, since currently it compiles too soon. I understand 
he's working on expression trees and so on. This will allow us to simplify 
the VM about 100 fold, since a more intelligent compiler can just produce 
conditional jumps for various loops and so on, versus how the compiler is 
at the moment, where it compiles loops into LOOP ... ENDLOOP bytecodes. 
Very ugly. The VM currently is too smart, and the compiler is too dumb. 
After we finish fully separating them, which I hope to have done soon here, 
Valentin will be making the compiler smarter, and then we'll strip the VM 
down to be dumber, so to speak.


>That's for now . I have just browsed thru the source.

Like I said, the current CVS source won't compile, because the VM and 
compiler are only halfway detached from eachother. :) And remember the VM 
is much more complicated than it will be when all is said and done. The VM 
has a huge amount of recursion, to handle looping and AND/OR order of 
execution and if blocks and so on. A more intelligent compiler will 
eliminate this by producing much more linear instructions.


>regds,
>Suresh.

Anyway, I'll say again, i didn't start Cup planning to write a language, it 
just ended up that way. I'm working on teaching myself a lot of these 
language design concepts and so on, and, Cup is making great strides 
towards some of these concepts as I learn more. So, bear with me. I didn't 
come into this having much experience with language design. :)

Keith

Re: [Cup-Dev] Cup API Rewrite

[Valentin I. <val...@ya...>]

                Keith,


        I don't think it's a good idea to have major changes from 2 people.
Since you already checked in something, it would be better, in my opinion,
if you could finish your changes (make it work as before).   And I will use
as "reference" you latest version.


Vali

----- Original Message -----
From: "Keith A. Jackson" <Ke...@AG...>
To: "Cup Language Development (E-mail)"
<cup...@li...>
Sent: Monday 20 August 2001 14:27
Subject: [Cup-Dev] Cup API Rewrite


Alright, I checked in some code that breaks everything. :) In the
current condition, the source won't compile, but, before I checked it
in, I tagged all the 'good' source. What I did is rewrite most of the VM
API stuff to adhere to the CupAPI-Proposed document in the doc
directory. The reason Cup won't compile now is I haven't yet done the
compiler side. I guess I'm kind of waiting to hear from Valentin, since
he's doing major compiler re-writing as it is. Valentin, any status
since we last talked? If not, I'll go ahead and get the compiler fixed
up to work with the VM again. If anyone needs to checkout the source
that compiles and works before this checkin, the CVS tag is
'before-api-rewrite'. That will get you the source right before I broke
it all. -grin- Anyway, not in the habit of breaking things, like I said,
but waiting to hear about the compiler before I proceed.

Keith

[Cup-Dev] Cup API Rewrite

[Keith A. J. <Ke...@AG...>]

Alright, I checked in some code that breaks everything. :) In the
current condition, the source won't compile, but, before I checked it
in, I tagged all the 'good' source. What I did is rewrite most of the VM
API stuff to adhere to the CupAPI-Proposed document in the doc
directory. The reason Cup won't compile now is I haven't yet done the
compiler side. I guess I'm kind of waiting to hear from Valentin, since
he's doing major compiler re-writing as it is. Valentin, any status
since we last talked? If not, I'll go ahead and get the compiler fixed
up to work with the VM again. If anyone needs to checkout the source
that compiles and works before this checkin, the CVS tag is
'before-api-rewrite'. That will get you the source right before I broke
it all. -grin- Anyway, not in the habit of breaking things, like I said,
but waiting to hear about the compiler before I proceed.
=20
Keith
=20

RE: [Cup-Dev] Source Tree Re-Structuring

[Keith A. J. <Ke...@AG...>]

Aye, shared libraries, a whole new 17 levels of obfuscation and
versioning issues. :) I'm in no hurry to start working on them. :)

Keith

-----Original Message-----
From: cup...@li...
[mailto:cup...@li...]On Behalf Of
Craig Reagan
Sent: Wednesday, August 08, 2001 11:03 AM
To: cup...@li...
Subject: RE: [Cup-Dev] Source Tree Re-Structuring


I'm not familiar with .so file in *nix either, DLL's are pretty straight
forward.  This is how all the api calls are made from a win32 pgm., you
typically create an import lib for each dll and then link that with your
program.  You don't have to do it that way but it's much easier than
manually loading the DLL and finding the subsequent address for each
function call.  Then you can include the DLL's with the import libs for
a source distribution, but of course the import libs won't be compatible
with MSVC++.

Craig


-----Original Message-----
From: cup...@li...
[mailto:cup...@li...]On Behalf Of
Keith A. Jackson
Sent: Wednesday, August 08, 2001 9:50 AM
To: cup...@li...
Subject: RE: [Cup-Dev] Source Tree Re-Structuring


No. In time, I want the libraries to also be built as shared libraries.
.so files for Linux and DLL files for windows. I'm not really familiar
with this subject, so, I'll have to learn about it yet. Including static
libraries isn't very useful, as it's really only worthwhile to a
developer. Shared libraries are the only libraries I'd want in binary
releases, as they're the only libraries really worth anything to an
end-user. (i.e., installing a Cup upgrade with new DLLs would thus
upgrade any Cup Applications on the user's computer, distributing static
libraries does not, and is only worthwhile if the cup applications are
rebuilt)

Keith




-----Original Message-----
From: cup...@li...
[mailto:cup...@li...]On Behalf Of
Craig Reagan
Sent: Wednesday, August 08, 2001 10:41 AM
To: cup...@li...
Subject: RE: [Cup-Dev] Source Tree Re-Structuring


The win32setup Makefile looks like no biggie.  What about the two new
libs, want them included in the binary distribution?

Craig


-----Original Message-----
From: cup...@li...
[mailto:cup...@li...]On Behalf Of
Keith A. Jackson
Sent: Wednesday, August 08, 2001 9:27 AM
To: Cup Language Development (E-mail)
Subject: [Cup-Dev] Source Tree Re-Structuring


Okay, I think the re-organization that was done on the CVS tree is
worthy of some description, so here goes.
=20
All sources have been split into one of three sub-directories, common,
vm, and compiler. These sources are either part of the vm library, the
compiler library, or, a library common to both. The only source still in
the root src directory is the source file that uses the libraries to
build the cup binary itself.
=20
The build process builds the common libraries (common and dmem library),
and then the compiler library, and then the vm library. These are
intermediate libraries. The next step is combining the libraries.
=20
The Cup VM library won't work without the common library routines, so,
they are combined like so:
=20
common, dmem, vm: libcupvm.a
common, dmem, compiler: libcupc.a
common, dmem, vm, compiler: libcup.a
=20
You can see the end result is three libraries. linking to both libcupc
and libcupvm is illegal, since that would mean the common libraries are
included twice, and you ought to have namespace collisions.
=20
Also of note is the include directory. Currently, all the old header
files have been merged into one huge cup.h header. This is temporary. I
will work on cleaning this up over time. Also, I'm not sure if libcupc
and libcupvm will really work by themselves. They may not. I'm not that
worried about it until I get the CupAPI documented and implemented, then
I'll make sure it all works to that specification.
=20
I don't think the winsetup Makefile will function anymore. Needs testing
with the new src structure.
=20
Keith - Randomly making huge changes to piss everyone off :)
=20
=20