Deep Blue C worth it?

[Harry Potter]

Hi!  I have the Deep Blue C compiler and just downloaded the manual.  Before I use it, is it worth using?  Are there any significant missing features?  I just want a preview, that's all.

[tschak909]

Good overview here: 

https://en.wikipedia.org/wiki/Deep_Blue_C

 

 

[+DjayBee]

45 minutes ago, Harry Potter said:

Hi!  I have the Deep Blue C compiler and just downloaded the manual.  Before I use it, is it worth using?  Are there any significant missing features?  I just want a preview, that's all.

Using the manual is always worth it.

[Harry Potter]

I looked in the manual and found a lot of missing features.  I'm sticking with cc65 for now.

[tschak909]

I thumbed through the wikipedia and AtariWiki articles on Deep Blue C, and have found a gross inaccuracy that is consistent anywhere that DBC is mentioned:

 

Deep Blue C is based on Ron Cain's Small C compiler. Correct.

Small C was first implemented on the 8080. Also correct.

However, this has been conflated to mean that Deep Blue C therefore implements an 8080 virtual machine in its back-end code generator. This is NOT correct.

 

If you...actually read either the user manual for Deep Blue C, or the Deep Blue Secrets manual which describes the source code to Deep Blue C, you will see that the code generator for DBC implements a simple "C" processor, not related to the 8080 or anything like it, at all. The first clue, is the $00 opcode ... which isn't a NOP. The rest of the instructions are sequentially defined, and do not match up with 8080 semantics, at all. 

 

Anyway, this should be corrected.

 

-Thom

 

[+bhall408]

I'd used DBC back in the day. After a while, we switched to ACE C, which was a variant of DBC.

 

It was great for doing projects where you wanted the resulting (p) code to be compact, vs code that ran super fast.

We used it to write a BBS.

 

More recently, the co-author of that BBS moved the same code to cc65, and it ballooned in size -- the ACE C version fit on an unmodified 800XL or 65XE. The cc65 version needs 128K!

 

[Kaj de Vos]

Chances are the source code needs a lot of tweaks to force CC65 to generate more efficient code. Not only faster, but also smaller.

[TGB1718]

1 hour ago, Kaj de Vos said:

Chances are the source code needs a lot of tweaks to force CC65 to generate more efficient code. Not only faster, but also smaller.

It's always the libraries, just a simple empty main() compiles to just over 500 bytes,

just add printf("Hello World"); and it's 2.8K

add one more line scanf("%u",&i); and now it's nearly 5.9K

I know they are probably 2 of the worst, using <conio.h> functions produces slightly smaller code.

but the more library functions you use obviously the worse it gets. 

 

Once a library function is used, repeated use doesn't increase the overhead other than the call

and variables used in the call.

[Harry Potter]

I have a program to optimize cc65 code called AtaSimpleIO.  It provides much more efficient code than the standard and console I/O functions by doing little or no extra overhead and processing.  You can find it at c65 additions - Manage /ui at SourceForge.net.  Try it out!

[danwinslow]

1 hour ago, TGB1718 said:

It's always the libraries, just a simple empty main() compiles to just over 500 bytes,

just add printf("Hello World"); and it's 2.8K

add one more line scanf("%u",&i); and now it's nearly 5.9K

I know they are probably 2 of the worst, using <conio.h> functions produces slightly smaller code.

but the more library functions you use obviously the worse it gets. 

 

Once a library function is used, repeated use doesn't increase the overhead other than the call

and variables used in the call.

This is very true. Most of the stdio stuff isn't really necessary, since there are lower level things available (conio, for one) or you could just do a specialized CIO call of your own. Keeping passed variables down to things that fit in a,x,y help too. Use globals a lot, etc. There are good threads here for optimizing cc65 for either time or space. Taken to the extreme, you do wind up using cc65 as sort of a very advanced macro assembler, and so then you begin to think, well, why not just use assembly?

I think something that would aggressively prune the libraries at link time would be helpful, analyze the code paths and drop anything out that didn't get called.

[Harry Potter]

Again, try AtaSimpleIO.  Also, I have a long list of optimizations of cc65 code available at c65 additions - Manage Files at SourceForge.net.  They should help.

[Harry Potter]

Also, some programs don't need some of the routines executed at startup.  Most of my programs don't need parameters from the command line, so I can replace in the crt0.s file the line "jsr callmain" with "jsr _main."  Also, for some programs, bss doesn't need to be cleared, so you can disable the all to zerobss.  Finally, some very small programs don't use library init and done code, so disabling those lines should help.

[+bhall408]

One of the reasons I like/prefer cc65 is that it is a cross compiler.

 

I've considered if it would be worth the effort to compile the DBC compiler and linker on my Mac, creating a Mac hosted DBC tool chain (that still output to Atari XEX).

 

Could even optionally allow curly braces

 

[Kaj de Vos]

The CC65 library stack is one of the causes, but it's not just that. CC65 derives from an old compiler design that doesn't do many optimisations. Some constructs do generate better code than others, but you have to change your program code to use those constructs. Typical C code doesn't compile very well.

[Mark2008]

On 12/5/2022 at 9:47 AM, Harry Potter said:

Hi!  I have the Deep Blue C compiler and just downloaded the manual.  Before I use it, is it worth using?  Are there any significant missing features?  I just want a preview, that's all.

The short answer is no, the longer answer is, it's worth it if you find it fun, of course.

 

I have Deep Blue C compiler, and I know that those that use C in their daily work - they kind of hope for something that doesn't exist.

 

They want a full featured C, that produces performant code, that allows them to treat C as an assembler replacement, because it just that performant.

Such a thing doesn't exist, in my view.  However, before I move on the discussion, let me say that KickC is a modern cross compiler that supports Atari 8-bit and is worth checking out.

 

In my view, the only way to get performance is with Assembly, so when someone chooses a langauge they shoudl check out how it supports assembly, because any significant project will inevitably require assembly.

 

Deep Blue C has its documented limitations.  Lack of Struct support, lack of floating point support.  But the question I first ask of any language, is how it supports the inevitable requirement of also using assembly langauge.

 

In Atari BASIC, the method is the USR command.   Deep Blue C also a USR command.  So it supports that, but it is one of my least favorite ways of breaking into assembly.  These days I just put my assembly code into an online compiler like here:   virtual 6502 Assembler (masswerk.at)

 

Just type in the code and it gives me a list of hex.  There are similar websites to turn a list of hex into decimal.  And an easy to use program to turn decimal into atari strings for passing to a USR$ command.  Even though it is as optimized in a way like never before - it's still tedious to debug this.

 

So Deep Blue C doesan't just support the USR command, it also has the keyword ASM, so you can say, hook into some ML you put in page 6 like this: asm 0x600;

 

It's written in that era where you could bang out some assembler in your Assembler/Editor cartridge, interface it to Deep Blue C in this way, but this still isn't so tedious.

 

Now cross compilers like cc65 and KickC, I still think C coders get caught up in using their C skills -and it's a trap into unperformant code.

 

I don't have any C skills, so my code usually looks like this:

 

While(1){

checkJoystick();

checkCollisions();

animatePlayer();

updateScore();

}

 

So what I'm using C to do, is flow the program and organize the code.  But the VBI and DLI code, is written in assembler.  I make very limited use of libraries, I make very limited use of even what would be very common C programming styles - and therefore I don't have much complaints about speed.

 

anyway thats my 2 cents, I do own Deep Blue C....it's cool and all, but I wouldn't think of it as a tool to make me more productive.

 

[danwinslow]

17 hours ago, Mark2008 said:

They want a full featured C, that produces performant code, that allows them to treat C as an assembler replacement, because it just that performant.

Such a thing doesn't exist, in my view.  However, before I move on the discussion, let me say that KickC is a modern cross compiler that supports Atari 8-bit and is worth checking out.

CC65 is as well. I personally think it's the best for Atari dev. You can get very near assembler speeds out of it, but you have to write the source code in a non-standard way. In-line assembler is supported well and the tool chain supports linking assembler modules written in the CA65 assembler that comes with it. Kick C is probably good too, I haven't used it though so I can't say.

[Wrathchild]

With KickC being like modern small-micro compilers (e.g. PIC) it is consolidating a lot of variables from analysis of their use and so you'll get a lot of re-use of a memory location (2 for 16 bit integer etc) and so many labels will have the same address and hence that will make debugging more difficult, so I prefer the CC65/CA65 combo   

[baktra]

I don't believe so. I would go cross-platform. Native C development environments for 8-bits are usually clumsy, because the computers were not powerful enough. At Atari, they were developing cross-platform in the 80s too, using assemblers executed on stronger computers. A 40-column screen doesn't help either.

 

When it comes to development using CC65, it is not a bed of roses, too.
I would always consider the following:

1. There is no rich library of functions for sound and graphics for Atari. Therefore, knowledge of how the Atari hardware works and how it is programmed is still essential.
   C65 is not at fault here, it is the way it is. One has to know assembler and how to interact with C.
2. One must know how the LD65 linker works. This is especially important when including data (like fonts, bitmaps, display lists) in the project.
3. Unsurprisingly, the generated code is not as good as handwritten assembler.

This makes the CC65 somehow sandwiched: 

• The assembler developers would complain about inefficient code and boilerplate syntax, fighting with the compiler. A better choice can be to stick with ASM.
• The higher-level language programmers who would find the library insufficient and do not want to deal with the intricacies of the linker. A better choice can be the Mad Pascal with richer library.

 

[TGB1718]

I tend to use cc65 for interactive programs or programs that process data and revert to MADS for

anything else, although I did write a program in cc65 to do plot/draw functions and was quite quick

although not very small

 

[Wrathchild]

I still like the 'discipline' of CC65->CA65 & LD65 in having to declare the imports & exports. It can be useful when disassembling code from games for relocation (e.g. A8 - > 5200) or porting (e.g. C64/BBC -> A8) as if the original code is written fairly well then areas of code will be isolated and can be split into separate source files with minimal interaction between them.

[danwinslow]

3 hours ago, baktra said:

I don't believe so. I would go cross-platform. Native C development environments for 8-bits are usually clumsy, because the computers were not powerful enough. At Atari, they were developing cross-platform in the 80s too, using assemblers executed on stronger computers. A 40-column screen doesn't help either.

 

When it comes to development using CC65, it is not a bed of roses, too.
I would always consider the following:

1. There is no rich library of functions for sound and graphics for Atari. Therefore, knowledge of how the Atari hardware works and how it is programmed is still essential.
   C65 is not at fault here, it is the way it is. One has to know assembler and how to interact with C.
2. One must know how the LD65 linker works. This is especially important when including data (like fonts, bitmaps, display lists) in the project.
3. Unsurprisingly, the generated code is not as good as handwritten assembler.

This makes the CC65 somehow sandwiched: 

• The assembler developers would complain about inefficient code and boilerplate syntax, fighting with the compiler. A better choice can be to stick with ASM.
• The higher-level language programmers who would find the library insufficient and do not want to deal with the intricacies of the linker. A better choice can be the Mad Pascal with richer library.

 

Beds of roses are hard to find, and usually have thorns somewhere 

If you are going to do anything serious in any language on the Atari, knowledge of of how the Atari hardware works and how it is programmed is always going to be essential.

The linker is complex, but that complexity allows the freedom to do things relatively easily that would be difficult otherwise.

The assembler developers would use the built in CA65 assembler rather than trying to write large amounts of in-line assembler.

There are libraries that support mouse, joystick, and some graphics stuff. Example code is also easy to find.

 

I would agree that CC65 would not be my first choice for a small project, unless I had already learned it, but power brings complexity.

Also agree that the 'C' part of it is in kind of a middle ground when writing for efficiency. You can get very efficient code generation, but you have to write in what amounts to kind of a very advanced macro assembler anyway so then you can feel like you should just use assembler anyway. I always preferred the setup from crt0.s and then drop into CA65 for things that really needed efficiency. But, I have written some really time-critical stuff in straight C (DLI, mouse driver, VBI, etc.) so it is capable of doing so.

 

Mad Pascal is a great choice, too, from what I can see, but you do lose some of the linker control you have in CC65.

Edited January 9, 2023 by danwinslow

[TGB1718]

Must admit I get stumped a bit with the linker

[baktra]

2 hours ago, TGB1718 said:

Must admit I get stumped a bit with the linker

Yes, the first encounter with ld65 is usually a harsh one.

But it is nothing compared to LD. On the other hand, when a common Win/Lin/Mac programmer needs to place data to a specific virtual/physical address?

 

[TGB1718]

I have used many UNIX linkers in the past, but never had the problem of trying to specify specific addresses, must be a pain

[sanny]

Try to link a UNIX or Linux _kernel_, then you'll have the problem of specifying specific addresses.

 

Remember, the 6502 doesn't support virtual memory.