Preliminary Work in CC65

[Guest]

I've done some preliminary work in CC65 to get a handle on the scope of the scripting language and what kind of performance we can expect.  Here's an example of some of the BASIC-like code I am targeting:

Code Select Expand

dim a as string
dim b as integer
dim i as integer
dim r as single
dim e as single

a = "Test"
b = 32767

print a; " "; b

i = 0
Label:
r = i / 2
e = int(i / 2)

if r = e then
call Even
else
call Odd
end if

i = i - 1

if i > 0 goto Label:

end

sub Even()
print "EVEN"
end sub

sub Odd()
print "ODD"
end sub
As you can see, this is a lot more modern syntax than BASIC 7.  It doesn't use line numbers, has real subroutines and functions, and even supports long variable names.  I've begun working on my code executor in C.  You can read more about that on my http://blogs.ittoolbox.com/visualbasic/dotnet/archives/falling-on-the-c-wagon-10572 blog.

[xlar54]

Im intrigued. (By the way, Ive bookmarked your blog site for other C# issues)  Are you planning to compile the code or will it be interpreted?  I have written a BASIC interpreter in C#, so if you need to borrow anything from it, feel free. It's old school BASIC (actually I wrote a BASIC BBS with it), with line numbers, etc, so it may not be too useful for what you are doing. Language writing is actually one of my fave programming topic, so I will follow this one closely.

Also, since this is for the BBS, rather than a general purpose language, Id skip the floating point stuff to save on space and time, and stick with integers.  And maybe even some memory and bit manipulation functions.  Do you have any idea yet what commands will be supported?  Disk IO?  

My assembly is getting better, and Ive been scouring the net for good 6502 code (some very 128-specific such as IRQ routines and time of day (CIA) stuff, VDC, etc) If you need any specialized code, let me know.

[Guest]

Im intrigued. (By the way, Ive bookmarked your blog site for other C# issues)  Are you planning to compile the code or will it be interpreted?  I have written a BASIC interpreter in C#, so if you need to borrow anything from it, feel free. It's old school BASIC (actually I wrote a BASIC BBS with it), with line numbers, etc, so it may not be too useful for what you are doing. Language writing is actually one of my fave programming topic, so I will follow this one closely.

I know what you mean.  Compiler design was my favorite class in my Computer Science major.  I was thinking about the run-time stuff and think that a JIT (just in-time compiler) is the way to go, but also to include the ability to pre-compile the BASIC files into the same execution tree as the JIT.  It's going to take some doing to figure out how to get the JIT to output an execution tree that can be saved and loaded on demand.  I was also thinking about using our PC Service to do the JIT script compilation, then we just have to worry about executing the tokenized code in the BBS.  This way, the BBS sysop never has to place the BASIC files on the Commodore and they would be loaded from the PC on the fly.  If the BBS has a really fast device like a RamLink then the BBS could cache precompiled files there.  Since the RamLink has a Real Time Clock and we can timestamp the files, it would be easy to expire the cache and force a recompile on the PC.

Also, since this is for the BBS, rather than a general purpose language, Id skip the floating point stuff to save on space and time, and stick with integers.  And maybe even some memory and bit manipulation functions.  Do you have any idea yet what commands will be supported?  Disk IO?

I am going to allow the script to call methods that are declared and in memory with the C infrastructure.  I'll probably make stub functions in the interpreted language to make it easier on the end users.

My assembly is getting better, and Ive been scouring the net for good 6502 code (some very 128-specific such as IRQ routines and time of day (CIA) stuff, VDC, etc) If you need any specialized code, let me know.

There's definitely a lot to do in Assembler.  We need SwiftLink routines written in CC65 C or CA65 Assembler (preferrably the assembler route).  We also need protocols written and such as drivers.  CC65 has a complete driver model that we need to get very familiar with.

BTW, all of this is just thinking out loud right now.  We have another design meeting this Saturday evening and we will probably be hashing out some more of the design requirements which will shape this conversation.  Right now, I'm just doing proof of concept work to make sure I haven't embarked on something I cannot accomplish on the 128.

[xlar54]

"BTW, all of this is just thinking out loud right now.  We have another design meeting this Saturday evening and we will probably be hashing out some more of the design requirements which will shape this conversation.  Right now, I'm just doing proof of concept work to make sure I haven't embarked on something I cannot accomplish on the 128."

True... and thats really what its all about anyway - see how far we can push this machine. Much of the assembly code Ive been working with is really just a "can it do that" type of thing. And Im learning more about the 128 itself, which is a big plus.  Thing about assembly, you cant just learn assembly, you have to learn the machine its running on also.  

I was initially opposed to CC65 as the development platform, and I still have some things to learn on it (config files made me nuts when trying to link).  At one point I thought Id be slick and write some C code and see what kind of assembly it would emit - but it was of course utilizing its own library, making JSR calls, and I had no idea how to decompile the library. (my short-lived quest on 16 bit multiplication, ultimately resolved).  

I see the direction you are going with the scripting language, and I can see that might work out pretty well indeed. I did put together some protoype code based on my overlay code for a BBS, it works pretty well even with VICE, but there are some bugs of course.  Ill toss it up somewhere and if nothing else, maybe someone will come along and make us of it.

[OzOne]

Unfortunately I'll miss this coming weekend due to work commitments, but I guess Lance will post the session ?

Oz

[Guest]

I was initially opposed to CC65 as the development platform, and I still have some things to learn on it (config files made me nuts when trying to link).  At one point I thought Id be slick and write some C code and see what kind of assembly it would emit - but it was of course utilizing its own library, making JSR calls, and I had no idea how to decompile the library. (my short-lived quest on 16 bit multiplication, ultimately resolved).

Download the sources for CC65.  They include the source to all of the library functions, most of which are written in CA65 assembler.  I have learned more about C and Assembler from reading those file than I have from the myriad books and helpsites available.  Since I really started programming in C++ before C, I'm having to "unlearn" a lot of things.

[Blacklord]

Unfortunately I'll miss this coming weekend due to work commitments, but I guess Lance will post the session ?

Oz

Yep, will do.