Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #3639 > unrolled thread

C vs Asm

Back to article view | Back to comp.sys.apple2.programmer

Contents

  C vs Asm anthonypaulo@gmail.com - 2017-07-06 21:40 -0700
    C vs Asm Antoine Vignau <antoine.vignau@laposte.net> - 2017-07-07 03:03 -0700
    C vs Asm Antoine Vignau <antoine.vignau@laposte.net> - 2017-07-07 03:05 -0700
      C vs Asm Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-07-07 18:24 -0700
        Re: C vs Asm James Davis <JPD.Enterprises@outlook.com> - 2017-07-08 00:26 -0700
          Re: C vs Asm Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-07-08 06:56 -0700
            Re: C vs Asm "Bill Buckels" <bbuckels@mts.net> - 2017-07-10 07:34 -0500
              Re: C vs Asm James Davis <JPD.Enterprises@outlook.com> - 2017-07-10 11:46 -0700
    Re: C vs Asm mmphosis <mmphosis@macgui.com> - 2017-07-07 16:25 +0000
      Re: C vs Asm Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-07-07 17:47 -0700
    Re: C vs Asm James Davis <JPD.Enterprises@outlook.com> - 2017-07-07 13:33 -0700
      Re: C vs Asm anthonypaulo@gmail.com - 2017-07-07 17:54 -0700
        Re: C vs Asm Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-07-07 18:04 -0700
          Re: C vs Asm qkumba <peter.ferrie@gmail.com> - 2017-07-08 08:53 -0700
    C vs Asm Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-07-07 17:45 -0700
      Re: C vs Asm anthonypaulo@gmail.com - 2017-07-07 18:01 -0700
        Re: C vs Asm Michael Pohoreski <michael.pohoreski@gmail.com> - 2017-07-07 18:17 -0700
    Re: C vs Asm "Bill Buckels" <bbuckels@mts.net> - 2017-07-08 07:55 -0500

#3639 — C vs Asm

I can't find the thread but I read a post here recommending doing all development in assembly because the C compilers generate bloated assembly that takes up way too much space. I don't believe it had to do with optimizations as it's most likely the case that the compiler can optimize better than we can most of the time, but I think it was more along the lines of the C compilers not really meant to target an 8-bit system and so generate bloated datatypes that utilize 16-bit word lengths instead of 8-bit when 8 suffices. Is there some truth to this?

[toc] | [next] | [standalone]

#3641

You mean C for 8-bit machines or 16-bit ones?
Apart from optimization, the amount of available RAM is a show-stopper for a majority of code targeting 8-bit machines.

Still from my disassembly years, compiled C is really A verbose and I am sure we could get an optimized asm code for the 16-bit. Some years ago, I disassembled then optimized the assembly from JPEG.View, its source code is in C. I have gained 1/3 of the time to have a jpeg/jfif pic displayed.

Antoine

[toc] | [prev] | [next] | [standalone]

#3642

There are plenty of IIgs pgms compiled from C, even games. When you write asm code for gfx animation, you can keep the logic in C.

Antoine

[toc] | [prev] | [next] | [standalone]

#3666

Considering Marble Madness (1984) was one of the very first commercial games to be written in C almost everyone on the Apple 2 was using asm at the time. =) And for many years afterwards.

It would be interesting to know what the very first Apple 2 game written in C is / was so we can have a time-frame.

As a professional game developer for many years C didn't start getting popular until around 1990 when 16-bit games such as the SNES started taking off.  It was clearly entrenched in the industry in 1995 but asm never really died until ~2015.  Anyone seriously programming the PS3 was definitely using asm to take advantage of the SPUs.

[toc] | [prev] | [next] | [standalone]

#3667

On Friday, July 7, 2017 at 6:24:30 PM UTC-7, Michael Pohoreski wrote:
> Considering Marble Madness (1984) was one of the very first commercial games to be written in C almost everyone on the Apple 2 was using asm at the time. =) And for many years afterwards.
> 
> It would be interesting to know what the very first Apple 2 game written in C is / was so we can have a time-frame.
> 
> As a professional game developer for many years C didn't start getting popular until around 1990 when 16-bit games such as the SNES started taking off.  It was clearly entrenched in the industry in 1995 but asm never really died until ~2015.  Anyone seriously programming the PS3 was definitely using asm to take advantage of the SPUs.

I remember seeing a pamphlet on 'C' at Computerland, Hayward, CA, USA, in 1977-8, at the same time that I was buying my first Apple II Plus.  It was a "Reduced Instruction Set" programming language at the time with just 21 keywords.  Years later there was "Hyper C for the Apple II."

[toc] | [prev] | [next] | [standalone]

#3669

On Saturday, July 8, 2017 at 12:26:48 AM UTC-7, James Davis wrote:
> I remember seeing a pamphlet on 'C' at Computerland, Hayward, CA, USA, in 1977-8, at the same time that I was buying my first Apple II Plus.  It was a "Reduced Instruction Set" programming language at the time with just 21 keywords.  Years later there was "Hyper C for the Apple II."

Well, C has also been called the poor man's assembler and/or a high-level assembly language. :-)

C is a such a beautiful, minimal language.  There is something magical about how just expressive and compact the language is.  (The same could be said about LISP in spite of the syntax making my eyes bleed.)

The joke about C being a RISC programming language has some merit to it.  C's strength is that almost every keyword maps very closely 1:1 to assembly -- at least on x86.  You can read a C program and almost instantly get a rough idea of the "code complexity."  In Contradistinction with C++ you get so much extra crap with virtual functions, function overloading, templates, etc. that is almost impossible to _reason_ about what the generated assembly will look like.  One line in C++ could generate hundreds of assembly instructions and you have NO clue.

C's strength is that it is low-level. :-)
C's weakness is that it is low-level. :-(

C's death has been predicted many times -- like a cockroach it will survive until the end of time. i.e. Witness how many fad programming languages like Perl, Python, Ruby,  the original Java compiler, Sun's JVM etc. are all written in C.

[toc] | [prev] | [next] | [standalone]

#3692

"Michael Pohoreski" <michael.pohoreski@gmail.com> wrote:
>C's death has been predicted many times -- like a cockroach it will survive 
>until the end of time.

Satan C Compiler

First I tore off the wrapping, Then I took out the Disk.
I never noticed the warning, Or the label that said "RISK!"
Then I picked up the licence, And read the Guarantee,
It said that all the code I'd write, Would be fully bug-free.
I put the disk onto drive A, the hard disk started to smoke
The smell of sulfur was everywhere, my eyes burned,I started to choke.
And then my amber monitor started glowing dark green,
and smoke rose as I saw the startup Screen.
And it said, Welcome to the SATAN C Compiler...
You'll write perfect code, it'll always load,,
We're so glad you bought the SATAN C Compiler,Bug Free's the Goal,
It'll only cost your soul....
I just stared at the terminal, I think it stared back at me,
Then I laughed at the practical joke, and settled down to use this C.
I wrote a HUGE multitasking Database just for fun,
With built in datebook and spreadsheet to boot
I never thought it would run...
I knew I'd left pointers dangling, coerced types every place,
My memory management problems with alloc
Not even lint could erase.
But I put in stub modules and prepared for the test,
It compiled in half a second flat, God was I impressed!
All the modules were working, Even the stubs were armed,
I knew right then and there my coding was great,
And my life must be charmed.
Welcome to the SATAN C Compiler,
you'll always write perfect code,
It'll always load,
But now you must pay for the SATAN C Compiler,
Although it works just swell, It'll never sell!
And now I sit in my Basement, Starving, Broke, and Alone,
I never speak to anyone, Although I sometimes moan.
But I Thought that I should warn you don't touch that disk,
The One that Infernal Business Machines Labels with 'RISK!'
But for me it's too late, I can't get out of this Hell,
I stab at ctrl-alt-del. But I just can't Kill the Shell.
All I get is one message. And The text makes me grieve.
"You can Logoff any time you like but you can never leave.."
Welcome to the SATAN C Compiler,
you'll always write perfect code,
It'll always load.
You better not go near the SATAN C Compiler.
If you do, my friend, It'll be your end.... 

[toc] | [prev] | [next] | [standalone]

#3693

On Monday, July 10, 2017 at 5:34:32 AM UTC-7, Bill Buckels wrote:
> "Michael Pohoreski" wrote:
> >C's death has been predicted many times -- like a cockroach it will survive 
> >until the end of time.
> 
> Satan C Compiler
> 
> First I tore off the wrapping, Then I took out the Disk.
> I never noticed the warning, Or the label that said "RISK!"
> Then I picked up the licence, And read the Guarantee,
> It said that all the code I'd write, Would be fully bug-free.
> I put the disk onto drive A, the hard disk started to smoke
> The smell of sulfur was everywhere, my eyes burned,I started to choke.
> And then my amber monitor started glowing dark green,
> and smoke rose as I saw the startup Screen.
> And it said, Welcome to the SATAN C Compiler...
> You'll write perfect code, it'll always load,,
> We're so glad you bought the SATAN C Compiler,Bug Free's the Goal,
> It'll only cost your soul....
> I just stared at the terminal, I think it stared back at me,
> Then I laughed at the practical joke, and settled down to use this C.
> I wrote a HUGE multitasking Database just for fun,
> With built in datebook and spreadsheet to boot
> I never thought it would run...
> I knew I'd left pointers dangling, coerced types every place,
> My memory management problems with alloc
> Not even lint could erase.
> But I put in stub modules and prepared for the test,
> It compiled in half a second flat, God was I impressed!
> All the modules were working, Even the stubs were armed,
> I knew right then and there my coding was great,
> And my life must be charmed.
> Welcome to the SATAN C Compiler,
> you'll always write perfect code,
> It'll always load,
> But now you must pay for the SATAN C Compiler,
> Although it works just swell, It'll never sell!
> And now I sit in my Basement, Starving, Broke, and Alone,
> I never speak to anyone, Although I sometimes moan.
> But I Thought that I should warn you don't touch that disk,
> The One that Infernal Business Machines Labels with 'RISK!'
> But for me it's too late, I can't get out of this Hell,
> I stab at ctrl-alt-del. But I just can't Kill the Shell.
> All I get is one message. And The text makes me grieve.
> "You can Logoff any time you like but you can never leave.."
> Welcome to the SATAN C Compiler,
> you'll always write perfect code,
> It'll always load.
> You better not go near the SATAN C Compiler.
> If you do, my friend, It'll be your end....

Nice poem.  Does the SATAN C Compiler really exist?

For Hardware, RISC is an abbreviation of Reduced Instruction Set Computer.

For Software, Reduced Instruction Set would be abbreviated: RISS

For Software Compilers, Reduced Instruction Set would be abbreviated: RISSC.

For the SATAN C Compiler (Software), Reduced Instruction Set would be abbreviated: RISSCC!  Use at your own RISK!!!  Note the K.  It means what it says.

[toc] | [prev] | [next] | [standalone]

#3645

This comes up from time to time elsewhere and it is debatable.  Compilers to

my knowledge don't know how to reason very well, ... yet? 

http://tratt.net/laurie/blog/entries/what_challenges_and_trade_offs_do_optimising_compilers_face.html


Hand assembly can be faster than code generated by a C compiler.  On a 
modern CPU, it makes little different except when it does.  It makes more 
difference, more of the time, on a 6502 running at 1 MHz.  For the logic in 
a program, code generated by the C compiler would be faster than logic 
written in BASIC or even compiled BASIC as it often has been done on the 
Apple II.  Write the logic in BASIC, and then hand optimize 6502 machine 
language for the critical parts of the program -- this is where the C 
compiler might be better. 

Show me a C compiler that generates 6502 code optimized to the max: 
register allocation, zero page allocation, unrolled loops, and all manner of

tricks that I've seen to remove 1 cycle.   

anthonypaulo wrote: 
> I can't find the thread but I read a post here recommending doing all 
> development in assembly because the C compilers generate bloated assembly 
> that takes up way too much space. I don't believe it had to do with 
> optimizations as it's most likely the case that the compiler can optimize 
> better than we can most of the time, but I think it was more along the 
> lines of the C compilers not really meant to target an 8-bit system and so
>
> generate bloated datatypes that utilize 16-bit word lengths instead of 
> 8-bit when 8 suffices. Is there some truth to this? 

You ask about code optimized for space, not speed.  The trade off of 
occupying a small confined space is slow speed most of the time.  Data can 
be hand optimized for space, using more compact types and compression 
techniques.  Some of the Apple II role playing games did this very well by 
compacting massive vocabularies, again, using all manner of tricks to save 
space -- this goes way beyond simple 8-bit vs. 16-bit types.  A 6502 C 
compiler might not be the best choice here. 

As for the code, it might make more sense to generate or write the code in a

language that might optimize better for space like a forth, PLASMA, Short, 
Sweet-16, BASIC, Pascal, or your own language / space optimized VM or 
runtime.   

https://en.wikipedia.org/wiki/Shannon_coding 
https://github.com/dschmenk/PLASMA/ 
https://bitbucket.org/martin.haye/super-mon/wiki/Short_features 

[toc] | [prev] | [next] | [standalone]

#3661

> Compilers to 
> my knowledge don't know how to reason very well, ... yet? 

Don't worry, x86 C compilers **STILL** suck.
https://github.com/Michaelangel007/write_code_compiler_can_optimize

[toc] | [prev] | [next] | [standalone]

#3651

On Thursday, July 6, 2017 at 9:40:18 PM UTC-7, anthon...@gmail.com wrote:
> ... the compiler can optimize better than we can most of the time, ...

If you think that (above), then take a look at this:

https://groups.google.com/forum/#!topic/comp.sys.apple2/EQmJAuNz8Vg

[toc] | [prev] | [next] | [standalone]

#3662

On Friday, July 7, 2017 at 4:33:16 PM UTC-4, James Davis wrote:
> On Thursday, July 6, 2017 at 9:40:18 PM UTC-7, anthon...@gmail.com wrote:
> > ... the compiler can optimize better than we can most of the time, ...
> 
> If you think that (above), then take a look at this:
> 
> https://groups.google.com/forum/#!topic/comp.sys.apple2/EQmJAuNz8Vg

Wow... you know that if they keep going at it at this pace they'll be down to one instruction in no time!

[toc] | [prev] | [next] | [standalone]

#3664

Yeah qkumba quit slacking already ;-) =P :-)

[toc] | [prev] | [next] | [standalone]

#3671

> Yeah qkumba quit slacking already ;-) =P :-)

Working on it.

https://groups.google.com/forum/#!topic/comp.sys.apple2/_y27d_TxDHA

[toc] | [prev] | [next] | [standalone]

#3660

> I can't find the thread but I read a post here recommending doing all development in assembly because the C compilers generate bloated assembly that takes up way too much space.

There are FAR too many threads but the general argument is:

It all comes down to two things:

1) _your_ time vs the Apple 2's _space_.
i.e.
If you _don't_ know 6502 assembly then a C compiler will get your code up and running faster.
If you don't care about run-time performance (time) then use a C compiler on the 6502.
If you don't care about memory usage (space) then use a C compiler on the 6502.

Use BASIC if you want to just get "stuff" working.  BASIC is great for prototyping.  Hell, use a BASIC Compiler if you want a little bit of speed.
But if you plan to do any sort of real-time graphics, assembly is (almost) only the only way to go.  I give a nod to GraFORTH, Graphics Magician, etc.

Some of us have been writing 6502 assembly since the early 80's -- it was my second programming language I learnt -- so using a C compiler for the 6502 is absolutely retarded _FOR me._  It provides (almost) ZERO advantage.

Hand crafted assembly will smoke the pants off anything written in C for the 6502.

Don't get me wrong.  I love C. I use it daily on x86.  (Well, non-bloated C++.)
i.e. Multi-threaded C++ rendering using OpenMP.
https://github.com/Michaelangel007/buddhabrot

But on a 6502 -- that makes no sense for some of us to use C when we _already_ know 6502.

If you don't know 6502 then use what you DO know.  I'd recommend learning 6502 assembly though -- it is very easy to learn, plus you will become a better programmer.  Plus it's a helluva lot of fun.

2) It all depends on the _context_ of the problem you are trying to solve.

Plotting a HGR lines? Use Applesoft and move on.
Real-time results?  Use assembly where it makes sense.
A game with HGR or DGHR graphics?  Man up, and learn 6502 assembly. :-)

There is no simple answer.

[toc] | [prev] | [next] | [standalone]

#3663

On Friday, July 7, 2017 at 8:45:47 PM UTC-4, Michael Pohoreski wrote:
> > I can't find the thread but I read a post here recommending doing all development in assembly because the C compilers generate bloated assembly that takes up way too much space.
> 
> There are FAR too many threads but the general argument is:
> 
> It all comes down to two things:
> 
> 1) _your_ time vs the Apple 2's _space_.
> i.e.
> If you _don't_ know 6502 assembly then a C compiler will get your code up and running faster.
> If you don't care about run-time performance (time) then use a C compiler on the 6502.
> If you don't care about memory usage (space) then use a C compiler on the 6502.
> 
> Use BASIC if you want to just get "stuff" working.  BASIC is great for prototyping.  Hell, use a BASIC Compiler if you want a little bit of speed.
> But if you plan to do any sort of real-time graphics, assembly is (almost) only the only way to go.  I give a nod to GraFORTH, Graphics Magician, etc.
> 
> Some of us have been writing 6502 assembly since the early 80's -- it was my second programming language I learnt -- so using a C compiler for the 6502 is absolutely retarded _FOR me._  It provides (almost) ZERO advantage.
> 
> Hand crafted assembly will smoke the pants off anything written in C for the 6502.
> 
> Don't get me wrong.  I love C. I use it daily on x86.  (Well, non-bloated C++.)
> i.e. Multi-threaded C++ rendering using OpenMP.
> https://github.com/Michaelangel007/buddhabrot
> 
> But on a 6502 -- that makes no sense for some of us to use C when we _already_ know 6502.
> 
> If you don't know 6502 then use what you DO know.  I'd recommend learning 6502 assembly though -- it is very easy to learn, plus you will become a better programmer.  Plus it's a helluva lot of fun.
> 
> 2) It all depends on the _context_ of the problem you are trying to solve.
> 
> Plotting a HGR lines? Use Applesoft and move on.
> Real-time results?  Use assembly where it makes sense.
> A game with HGR or DGHR graphics?  Man up, and learn 6502 assembly. :-)
> 
> There is no simple answer.

I hear ya... I already know 6502 assembly language, taught myself at the age of 10 and wrote my own assembler, but now at 43 I've been away for so long I figured the scene must have changed somewhat. Thanks for all the input... I was doing some research on the CC65 and the Aztec C compiler (sheesh, some bad blood between those folks!) but I think you've made up my mind. :D Now I need to learn me some Merlin...

[toc] | [prev] | [next] | [standalone]

#3665

>  I was doing some research on the CC65 and the Aztec C compiler (sheesh, some bad blood between those folks!)

Part of the problem with the CC65 suite is that it was originally written by someone who has never actually _used_ an Apple 2 assembler so its assembler, ca65, is lacking _basic_ features. No ASC '...' or ASC "..." directive?!  No HEX directive?? WTF. *facepalm* Hey, at least it supports #<var and #>var for low and bytes, so it isn't completely useless out of the box.

Seriously, ORG has been a defacto standard since at _least_ 1980.  Almost every Apple 2 assembler: Apple's EDASM, Merlin, etc. use it.  Heck, even Microsoft's MASM on x86 uses it!  https://support.microsoft.com/en-us/help/39441/the-org-directive-and-actual-offsets

Due to NIH the ca65 author felt the need to invent all their own proprietary crap, er pseudo-directives, such as .org instead of using _standard_ mnemonics that everyone else has already been using for _decades._

I have no idea about the code quality of the rest of the toolchain since I don't use a C compiler on 6502.

Merlin is a cool assembler.  Definitely checkout Merlin32!
https://www.brutaldeluxe.fr/products/crossdevtools/merlin/

[toc] | [prev] | [next] | [standalone]

#3668

<anthonypaulo@gmail.com> wrote: >I can't find the thread but I read a post 
here recommending doing all development in assembly because the C compilers 
generate bloated assembly that takes up way too much space.

It makes me wonder what kind of bloated C an assembler might generate. Maybe 
I've wasted all those years writing in C tweaking the critical parts with 
assembler and instead I could have just written in assembler and used the 
assembler to generate C code for the non-critical parts... :) JK... On 
second thought, I'll just stick with what I do...

Mixed-language WELL WRITTEN C with assembly is a more sensible general 
approach than doing all development in assembly as far as I am concerned, 
and usually far more readable from my view, which is another goal of real 
programming as far as I am concerned.

As far as 6502 cross-compilers, cc65 generates faster and smaller Apple II 
code than Aztec C, and both provide either inline assembly or linking of 
external object modules. I have written extensively on this and provided 
examples ad infinitum, so if you are interested you will find those...

Since game development was not the only development that developers in the 
80's and 90's did, it was not always necessary to write highly optimized 
code, but many of the the other self respecting developers I worked with 
avoided programming in BASUC with line numbers, and preferred working in a 
structured compiled language rather than interpreted spaghetti...

Regards,

Bill

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web