Many people seem to dislike to WDC Tools suite.
Saying it is old (no dispute there). Saying it is clunky (probably depends on what you are used to).
Saying it has many bugs/quirks. As long as, you are aware of them and can work around them, I call them "gotcha's".

As a beginning .asm and C programmer, with around 4 months of overall experience solely with WDC Tools (and none with CA65 or similar). I combined it with Notepad++ instead of TIDE. These are the gotcha's I have found/encountered so far.

1) Assembler (wdc02as/wdc816as)
- No spaces allowed around '+' in an equate: "STAT EQU BASE + 1" will have "STAT EQU BASE". Needs to be "STAT EQU BASE+1".
- Do not use the "REPT cnt" directive combination to auto-repeat cnt times an assembly statement. Assembler will crash. Need to manually replace/insert.

2) C Compiler (wdc02cc/wdc816cc)
- Some common datatypes are not standard included (e.g. uint8_t, uint16_t, uchar, ushort, ulong, etc.). Need to be user-defined.
- There is no prefix for binary values (e.g. in bitmasks etc). Must use HEX, octal or decimal.

3) Linker (wdcln)
Did not find anything so far.

4) Debugger (wdcdb)
- Needs to be run as Administrator
- Requires -hz (and -sz??) options during linking for the debugger to load/execute your code properly.

Are you aware of items you can add to the above list? Hopefully including workarounds or solutions.

PS : I am updating the above list as people respond, saving you reading the entire thread. Thank you for those who contribute.

another thing for the C compiler, it doesn't support binary notation. it doesn't even tell you that anywhere, not in the documentation, an error message, or error number.
it just kinda prints out the first line with binary from the source file on it and then quietly crashes (and yes the compiler does actually appear to crash instead of exiting because the return code is "-1073741819" instead of "0", "1", etc.)
it took me so god damn long to figure out why i wasn't able to compile by mandelbrot program. well turns out it had some binary masks in it!

the reason why it doesn't have binary notation is because it technically isn't part of the C standard ("0b" is a GNU GCC extention that a lot of other compilers have adopted) so WDC didn't include the functionality, which IMO is a very strange decision considering that the Compilers are for CPUs that very often deal with individual bits and masks...

C doesn't define uint8_t and so on. It's not part of the language standard.

Also note that the WDC C compiler is relatively old - it may well be ANSI C, but is it C89, C99, ... ?

C99 introduced the concept of a <stdint.h> file to define these types for you - some older C compilers also had it too but it may well have been very implementation dependant.

So - all you need to do is copy this file from another implementation that can use it, adapt as needs and use it.

And again binary prefix isn't a standard part of C ...

See here for an interesting way to do it:

https://www.thecodingforums.com/threads ... -c.318127/

So while I'll probably never use the WDC C compiler (because it doesn't run natively under Linux and cc65 is good enough for me) in this case I suspect it's not really at fault...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

A couple of gotcha's I've run into:

• farmalloc doens't work WDC816CC and farmalloc. ~~far_heap_start and ~~far_heap_end seem to be ignored and no more than 64KB of memory can be allocated.
• Low Level I/O functions don't exist WDC816CC and sprintf. Using FCNTL fails with an undefined symbol at linker time.
• Development of the Terbium IDE seems to have been abandoned in the Windows XP days WDC Terbium IDE (Tide) with the W65C816
• The peephole optimiser generates incorrect code when calling a function and assigning the result into a pointer referenced as an array when that pointer is a function parameter. (WDC are currently investigating this)
• WDC816CC understands large code that can cross banks. WDCLN does not and will generate an error if the resultant binary is larger than 64KB.
• Parameters can only be passed on the stack. Internal functions (like ~~~mul) can be called with parameters in A and X but the WDC816CC can't generate those functions.
• WDC816CC error messages seldom point to the correct line and tend to be a little generic I.e. everything is always 'Bad Declaration'.

And after that list it might seem like I dislike the WDC Tools but... nope. I'm quite enjoying using them. I've quite a large project going so far with good mix of C and assembly. And - sometime in the future - I want to post a tutorial on how to use WDC's tools with the W65C816.

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

WDC816CC doesn't generate great assembly. But. It does generate assembly specifically for their optimiser. WDC claim that the WDC816OP optimiser will net a 10% reduction in code size but I think they've undersold it - it seems pretty good to me.

It really is, there's a bunch of boiler plate that happens in every C method. Six instructions set up the Direct Page to point to the Stack on entry but once that's done all the arguments into the function and local variables in the function can use Direct Page addressing. Very spiffy. (And better than my own idea of growing the Direct Page - with local variables - up memory whilst growing the stack - with arguments - down memory).

Another 10 or 11 instructions put the stack back how it was (with a bit of mangling to make the RTL / RTS line up) and also put the direct page back how it was. X and A don't seem to need to be preserved. Which makes a bit of sense as they're used for the return value - when necessary - and typicaly values that do need to be preserved are stored in pseudo registers in the Direct Page. All round it's pretty neat.

With all of that said: Even good C is still multiples of times slower than assembly and tight loops (or anything time critical) still needs to be hand crafted in assembly.