I'm trying to use CC65 to compile some C code I found online. The code uses a struct with union and gets some odd errors. I was wondering if anyone has experience with CC65. The code and the errors are below.



cl65 -DBDWGC=0 -DCC65 -t none -C sbc2rom.cfg -o lysp.65b -m lysp.map -l lysp.c c:\cc65\lib\sbc2rom.lib
lysp.c(84): Warning: Declaration does not declare anything
lysp.c(87): Error: Struct/union has no field named `mNumber'
lysp.c(88): Error: Struct/union has no field named `mString'
lysp.c(88): Warning: Converting pointer to integer without a cast
lysp.c(89): Error: Struct/union has no field named `mString'
lysp.c(89): Warning: Converting pointer to integer without a cast

You're trying to use an anonymous union, which isn't standard C. Well, it might be these days, since it's a jolly useful feature, but in the past it wasn't.

Try this:


And to use it,

Thanks, that was it. It's been a while since I worked in vanilla C, me in 1990 would have been wise to that one. The other gotcha so far was inline functions which aren't in CC65 either.

CC65 is more like K&R C than ANSI C.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, the author liked to intersperse local variable allocations as they are needed. Gcc is fine with this, but CC65 will have none of it. It's only moving a line of code here and there, but it is tedious. In total this is about 1200 lines across two modules, so the effort mounts up.

You already got the solution for the errors, but I wanted to add some information. This applies to standard C compilers, I know there are some differences in cc65 so I'm not sure if this is useful in this context.

The first line in that code snippet doesn't declare anything. The name that follows the "struct" is the name of the struct type. This can be followed by a list of members, or a name of a variable if the compiler already knows which members are in the struct. If you follow the struct keyword with just the name of a struct type, it doesn't give the compiler any new information, so it gives you a warning because it thinks you may have forgotten something. A line that just contains "struct _Cell" is like a line with just "int;" in it.

The second line tells the compiler that your custom type "Cell" is the same as a "struct _Cell". Even if you haven't given the compiler a member list for struct _Cell, it's okay to declare an equivalent type. It's even okay to declare a pointer to a Cell or a struct _Cell, but you can't declare a variable of the struct until the compiler knows what members it has.

In fact, declaring a struct type and using pointers to them without letting the compiler know what the members are, is called "opaque structs" and is a great way to implement object-oriented software in C. Example:

Thanks for the information Jac.

I've made great progress today and have nearly all 927 lines of the first module compiling. I'm down to code which uses macros to take a variable argument list and call another function with the same argument list. I'm not sure what the CC65 replacement should be, but if this was assembler it would be a JMP instruction. Here's the C code which uses some gcc buitins to do it:



cl65 -DBDWGC=0 -DCC65 -W -t none -C sbc2rom.cfg -o lysp.65b -m lysp.map -l lysp.c c:\cc65\lib\sbc2rom.lib
lysp.c(457): Error: Call to undefined function `__builtin_apply'
lysp.c(458): Error: Call to undefined function `__builtin_return'

Not sure what to do with this one.

We'll need more context to figure this out. How is the macro defined? What function does it call? What is it trying to accomplish?

Basically the __builtin_apply and __builtin_return are GCC-specific intrinsic functions to forward the arguments of the current function to another function. Google for __builtin_apply and __builtin_return for more information (but it may not help you very much unless you have a thorough understanding of how compilers work, sorry).

In many older C compilers, the preprocessor can't even do variable arguments. Usually it's possible to work around this by using tricks. For example, I have a logging system that basically does this:



Hope this helps.

===Jac

I forked a Lisp interpreter that's supposed to fit in about 21 kb. So it seems perfect to port to an eight bit machine. Here's a link to the module in question:

https://github.com/Martin-H1/lysp/blob/master/lysp.c

What is happening is that each time a function is defined, a pointer to that function is retained and bound to its name. When an input token matches a function name, the function pointer is pulled from the binding and dispatched to the function using those GCC built-ins (which I thought were macros). The variable arguments is because a function has a user defined number of arguments, so the generic dispatch mechanism passes the entire set of parameters defined by the call in the program source.

So what is needed is a way to call a function pointer with the list of variable arguments already on the stack.

Update: in reading the code again it traverses the input argument list and pushed it on the stack. So if the psubr function type changed to accept arguments as a list this might eliminate the problem also.

I have to say I never used the __builtin_apply and __builtin_return functions before. Now that I look at it a little closer, it looks like they do a little magic to make it possible to call a function indirectly without knowing what its parameters are, passing the parameters from a variable argument list.

I'm not thoroughly familiar with Lisp/Lysp or CC65 and I haven't studied the code long enough to see the circumstances in which the apply( ) function can get called. But I see that the code that handles a cell with an mTag of PSubr builds a local array of 32 void pointers on the stack and then calls the primcall function with the function pointer from the cell. Since the function pointer is always the same type, it seems to me that it should be possible to call the function pointer directly, using the array.



You can then remove the entire primcall function, I think.

Note that there is a danger of stack overflow in the apply( ) function because while it fills the local argv array, it doesn't check if there's an overrun. I didn't dig into what "eval(car(args), env)" does but if it returns nonzero too many times, you have a stack trashing zombie on your hands . However, I also didn't know what the best way would be to bail out if there were too many arguments, so I just inserted a comment so you can keep it in mind for later. It may be easy to figure out how long the list of arguments is without getting them (again, I didn't dig into the code) but the comment is right: it should determine the length and alloca to allocate argv on the stack instead of trusting the caller to set up 31 arguments or less.

I also didn't dig into the reason why the arguments are stored from index 1 and argv[0] is set to the address of argv[1]. The functions that can be called through this mechanism had better know what they are doing .

===Jac

So I have a work around for the builtins. I will comment them out for now and add them to the to do list. That way I can continue getting the code to compile and link. When I start debugging I have a lot of things to worry about before getting anyway near that code.

The latest gem is that GCC allows pointer arithmetic on void *, which isn't allowed by other C compilers. It is also used throughout the garbage collector. So this should be fun to replace.