Hi all,

I know that Toshi must be very busy, so I was hoping that anyone else here with experience with lcc816 might be able to help.

From what I can tell, lcc816 is either generating output for Orca/M or XA65816 assemblers, not sure which off hand - I would like to modify it to generate output for the Cross32 assembler and have certain things generic for homebrew computers (ie: jumping to the output function to place a character on the screen), but I have no idea where to start to do this - any tips would be most appreciated. I'd really like to use it for some of the development to make my life a little easier, and I can't afford avocets compiler

-Tony

_________________
-Tony
KG4WFX

It's generating output for ORCA/M.

A key feature of the C language is the separation between the language and I/O. So, in order to change the I/O, no compiler changes are necessary.

Basically, all you have to do is write your own printf() function.

Toshi

Hi Toshi,

first off - I want to say how impressed I am that you did this, you did a wonderful job and I know I'd have been completely lost if I were trying to do what you did (compiler and interpreter design/redesign was not something I have ever studied)

Ok, now onto the question...

With the output currently for Orca/M - I need to convert this to pump out appropriate code for Cross32.

I know its dag2gs2 that I need to modify, and I know some of what I need to modify is in the opt0.dag and opt1.dag files - and I *think* the rest of what I would need to modify is in the gen.c file, but I'm not sure.

ie:

For orca, obviously something like:

_variable equ 15

sets variable to 15, where in cross

_variable: equ 15

sets variable to 15, it's slight differences like this that I need to modify.

This also affects labels and such. Another major difference is the way data is set.

I also don't know if things like:

BEQ *+12

will work in my compiler.

Are handlers of this nature in gen.c? Or are they elsewhere?

Also, is there a way to get dag to put its variables mostly outside of the "zero" page area?

Does it handle inline assembly well? for example - for me to go and make a printf function, after I get the string and any other variables into one final string, I need to call a function I've already written and tested in assembly to display the string...

I'm also not sure where the r15 came from, I'll have to locate my copy of the orca/m assembly manual I know I have floating around here so I can properly convert what I need to...

I appologize for all of the questions, I really appreciate it tho!

_________________
-Tony
KG4WFX

You may not need to modify dag2gs2 at all. The system was designed so all the functionality is the data files.

opt0.dag contains the base functionality required to compile all code. opt1.dag contains optimizations for some common dag combinations. This was done so it's easy to debug.



You need to read the opt0.dag and opt1.dag files.

Some are generated in opt0, some in opt1.



They're not in zero page. They're on the stack if I understand your question correctly.



No, LCC does not handle inline assembly.



Sure, no problem.

You really need to read opt0.dag and opt1.dag.

dag2gs2 basically has no intelligence. It's basically a pattern matching utility that outputs a string when a pattern is matched. All the patterns are in the opt0.dag and opt1.dag files.

Toshi

I've looked thru the dags extensively, I think for the most part, as you have mentioned, that I will be able to make the modifications there, except for a few things...

ie:

predefined data - this doesn't appear to be handled in the dags, whether it be the equ statement or the data/dc lines. As our compilers work differently in this regard, I'll have to figure out how to tweak the code to make it work





I'm still not sure where some of itcomes from, even looking thru the dags, I'm not sure what exactly it was trying to do - I'm sure this is because of the way orca dictates coding for relocateable programs (like the r15 question - I have no idea where that r15 appeared from, I'm assuming at this point it is something that has to do with orca as a single example in the opt0.dag...

RETV()
lda r15
add.l #local
sta r15
rts

it appears that r15 is important.... I know (or I think I know) this return is a return from void, but I don't know why it appears to be storing a return value (or at least, that's what I'm guessing r15 is?)

It's rather interesting to see how two ways of handling a single language can cause confusion

Once again, I do appreciate all of the help. I'm studying my orca/m manual now for how it handled things, and then I'm going to try at the dags again to conver them to my compiler, then go in and convert any source code to handle the other tweaks (like data storage, equ statements, etc.).

-Tony

_________________
-Tony
KG4WFX

I thought I posted a reply to this a few days ago, but it didn't show up.

There's definitely a TCS missing at the end of the LINK macro. This moves all the local variables onto the stack.

The 65816 backend for LCC pretends the 65816 is a 32-bit machine with 16 registers, and that's where the R0-R15 references come from. You need to set aside memory for R0-R15 (32 bits apiece) somewhere in memory.

The package is missing the macro file I used to handle the lda.l and sta.l macros. These load a 32-bit value into the X & A register pair.

Toshi

Hmm, you don't by any chance still have that macro file floating around somewhere, do you? or perhaps remember which register, A or X had the lsw and msw?

_________________
-Tony
KG4WFX

X has the upper, A has the lower.

I will have to look at my Apple //gs disks to see if I can find it...right now I'm on my way to Taiwan, so I'll look when I get back.

I can still answer questions in the meantime, though.

Toshi

Hi Toshi,

It's been a while, and I've gotten distracted, but I never quite forgot about this I was wondering if you ever found those extra macros you had mentioned.

_________________
-Tony
KG4WFX

Nope, haven't found them. I don't have a GS/OS boot disk so I can't view my disks.

Toshi

No worries, I completely understand.

I'm no compiler expert and since I don't fully understand the dags, I decided to take the plunge and invest in the avocet compiler package. expensive, but should be worth it in the long run for larger experiments that I don't want to code in assembly.

_________________
-Tony
KG4WFX