Janik asked me to drop by and say a few words about the compiler and assembler we are wanting to use, so... I've been working on getting Jolse Maginnis' lcc backend to generate code that can be assembled by ca65 and remove the dependencies on Wings. That's just the beginning, though...after that portion is complete, then it's time to start hacking out a libc that is portable enough to be used not just for our project.

I originally had plans to write the compiler from scratch, but shelved that idea when I got my hands on Jolse's lcc backend. I also thought about using xa or gas from binutils as the assembler, but I have settled on ca65 for the moment because of the other tools it provides -- namely a linker.

I've asked this before to the cc65 mailing list, but I'll ask here -- If there's any interest in working as a team on getting a functional compiler for the 65816 that doesn't cost a small fortune to own, why don't we pool efforts?

ccureau:

It might be good to take a look at Toshi's lcc port already - right now it generates code that is compatible with Orca/M compiler, I'm in the midst of working on converting it to work with the Cross-32 assembler (I really like this assembler as it works for a wide variety of targets, Garth introduced me to this one, and I have been using it ever since).

But with regard to the lcc port - only a few things need real heavy conversion - the DAG files that contain the pattern matching info to generate assembly, and then there is some source that needs to be modified -

2 reasons I have found so far -

1 All variable assignements seem to go at the base of the directpage (or 0 page in emulation mode) and go right thru the stack without stopping...

For example:

int a = 0, b,c,d,e,f,g,h,i,j,k,l,m,n,o,q,r,s,t,u,v,w,x,y,z;
int *p = (int *)0x4000;
char name[200];
int values[400];

ends up coming out as:
_y equ 1
_b equ 5
_c equ 9
_d equ 13
_e equ 17
_f equ 21
_g equ 25
_h equ 29
_i equ 33
_j equ 37
_k equ 41
_l equ 45
_m equ 49
_n equ 53
_o equ 57
_r equ 61
_s equ 65
_t equ 69
_v equ 73
_w equ 77
_x equ 81
_z equ 85
_p equ 89
_name equ 93
_values equ 293
_a equ 1893

As you can see - the array name was set to start at 93, and the code will generate if you store at say name[190] it will generate code that does something like:

lda #value
sta _name+190

which will put part of the variable right in the middle of the default stack space.

or something similar. So, it would seem that either one would have to shift all variable definitions into ram above the stack, or would have to build some way into it to store some variables in the first 256 bytes, but the majority outside of that region.

The other problem is the way it generates fixed data...

#define prompt "Login: "

the interesting thing is that unless a given piece of data is used, it isn't generated in code - which could be good or bad, but let's say you defined prompt, and then later used it in the program, it would generate a data section that looks like:

-0 data
L4 entry
dc i1'76,111,103,105,110,58,32,0'

so those are really the only few things that would need to be changed in hard code, everything else appears to be settable in dag files which you could litterally have multiple custom dags setup - ie: 1 to handle non relocateable code, and 1 to handle relocateable code; one for 6502 mode and one for 65816 mode, etc.

I do agree that more heads are better then one tho. Toshi has done a wonderful job so far, now its a matter of tweaking and building other modules for it.

_________________
-Tony
KG4WFX

I had briefly looked at Toshi's lcc port, but didn't get too involved in the details of it. If I understand correctly, this port is based on lcc 1.9, while Jolse's is based on lcc 4.1. It seemed to me that it would be much simpler to keep the code as much in line with the current tree as possible...that way we don't have to reverse fit fixes into version 1.9...

There's that, and the unusual method needed to get assembly out of Toshi's port. I guess it's a personal preference, but lcc alone is more pleasing to me than lcc, then rcc, then dag2gs2.

I'd like to put those test cases into Jolse's port and see what happens...I'll post the results here.

Hmm, you have a valid point. I haven't looked at lcc by itself, how difficult does it look to convert the current lcc to what is needed?

_________________
-Tony
KG4WFX

It doesn't appear to be too difficult to change the things we need changing in the 4.1 build, but I still don't like the way it is so dependent on JOS/Wings to compile with. Changing the assembly output is as simple as changing the .md file. There weren't too many other things Jolse changed, from what I remember. I can make a 'package' available for you to look at. I use Linux, but it should compile wherever the gcc suite happens to live.

There are two things that need to be addressed in addition to what we've already covered. First, it would be nice to have this code in the current (4.2) build, rather than 4.1. It's not as simple as a straight data move, but I don't imagine there are too many changes that need to be made. Also, the compiler does not do floats -- not a show stopper, but it certainly is a nice to have...

actually, were you able to download Jolse's port of lcc, or are you using a more raw version of lcc? I wasn't able to get the lcc port, it seems that portion of the jos site is broken...

_________________
-Tony
KG4WFX

I wound up downloading a modified lcc source from http://www.king.igs.net/~billnacu/wings ... ds/lcc.tgz . You'll also need the Wings source, which you can get from sourceforge's cvs in project wingsos -- download the wgs-src tree. There are instructions in the lcc.tgz file for how to compile. Warning -- there are many hard-coded paths here...

Don't forget most DRAMs have a cycle time that is twice the access time so 70ns parts often won't work above 7MHz.

Lee.

It's slightly worse than that....
(I'm sounding authorative here, but I could be hideously wrong. Please correct me if I am)

At 5v the setup time for BA0-BA7 is 33ns. So you don't even have 70ns worth of time... More like 37ns, possibly 27ns -- I can't quite figure out if you must have the data ready by the end of tACC on the data sheet or if it's okay to not be ready until Phi2 is falling.

So with a 100ns cycle time, you have at best, 67ns. So 70ns is a little too slow for that, just by a tad. You do have to remember that these are maximum times, so what's most likely happening is that the SIMM is sometimes, but not always, able to respond with enough time.

So, unless I'm wrong, you will probably end up with a 8 MHz or thereabouts clock for the machine.

I'd love to help out and I am wanting to do a 65816 computer, but I'm not really sure how much time I'm going to have to spend on it right at this moment... I have too many crazy projects that I want to do and have to pick and choose which ones I work on at any given moment.

Well, I tinkered with lcc 4.2, and managed to incorporate the mods into it, kind of.

I haven't modified anything yet in the mips.md file which is needed to be modified for the compiler, but as a sample of the current output...

C code:

main ()
{
int i;

i=54;

printf("Hello world!");

return 0;
}



Assembly output:


.(

mreg = 1
mreg2 = 5

.al
.xl

.include <65816.i65>
.include <lcc.i65>

.export _main
.text

_main .(

RZ = 8
LZ = 10

!PRO LZ
lda #54
sta RZ+1
pea ^L2
pea !L2
jsr @_printf
!POP 4
ldx #0
L1
!POST LZ
rtl
.)
.text
L2 .asc "Hello world!",0
.)

has a bit of a wierd way of defining variables, but that may just have to do with the nature of the assembler it was meant to match to.

I'm not sure which way would be better. 4.2 is definitly more current then 1.9, but it is possible to change the dags in external files without having to recompile everything to make it work....

_________________
-Tony
KG4WFX

Maybe it's just me, but does it really gain us anything to have the dags in external files? It saves us compile time, sure...but the whole thing compiles in under two minutes on my machine...probably closer to one minute.

I think the variable strangeness you are seeing is due to the target assembler, which is included in the wgs-src directory I had mentioned. Have you ever used the assembler that is in binutils? I've built it, but I can't find any documentation on it...

No, honestly, I hadn't used the assembler - heck, i still have to get the wings os on the system, this was taking the adjusted files from cvs for lcc and half incorporating them into 4.2 (some things evidently were changed in 4.2 compared to 4.1 so it makes some of the versions of code in his modifications not work right with everything else.)

I was planning on trying to get wings os today if possible and looking at it. Depends on how busy I am at work today as to whether I will have time or not.

Personally I like my cross32 assembler, but at this point I'd be pretty flexible just so I could use C.

-Tony

_________________
-Tony
KG4WFX

it'd be nice if there was a single package with the wingsos all together in, I don't like using cvs to get a gazillion files that could just as easily be put in a single tgz.

_________________
-Tony
KG4WFX

I assume in terms of the assembler, you mean ja.

I played with it a few moments ago and it seems pretty straight forward, just run ja <filename> and it will create <filename>.o65 which will then need to be linked using the jl65 tool....

I did find a few docs, although I'm sure you already knew about these - in the wgs-src folder, under docs, ja.txt...

_________________
-Tony
KG4WFX