Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: mmphosis Newsgroups: comp.sys.apple2.programmer Subject: Re: C vs Asm Date: Fri, 7 Jul 2017 16:25:31 -0000 (UTC) Organization: Mac GUI Lines: 52 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 7 Jul 2017 16:25:31 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="b2d8e1c5e704dda46140961a3f6d589c"; logging-data="1945"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19IEM1y7IFpBP7CoLpdEhcv" User-Agent: Mac GUI Usenet In-Reply-To: Cancel-Lock: sha1:X2mMhePYXBt/NbzxvF5Egszyx9s= Xref: csiph.com comp.sys.apple2.programmer: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