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


Groups > comp.sys.apple2.programmer > #3644

Re: Targeting both Apple II and IIgs

From mmphosis <mmphosis@macgui.com>
Newsgroups comp.sys.apple2.programmer
Subject Re: Targeting both Apple II and IIgs
Date 2017-07-07 16:18 +0000
Organization Mac GUI
Message-ID <mmphosis-1499444555@macgui.com> (permalink)
References <a73e3245-a26a-400a-bd3a-6a749f1f5d3b@googlegroups.com>

Show all headers | View raw


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 a
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

Back to comp.sys.apple2.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Targeting both Apple II and IIgs anthonypaulo@gmail.com - 2017-07-06 21:30 -0700
  Targeting both Apple II and IIgs Antoine Vignau <antoine.vignau@laposte.net> - 2017-07-07 02:59 -0700
  Re: Targeting both Apple II and IIgs David Schmidt <schmidtd@my-deja.com> - 2017-07-07 11:06 -0400
  Re: Targeting both Apple II and IIgs mmphosis <mmphosis@macgui.com> - 2017-07-07 16:18 +0000
    Re: Targeting both Apple II and IIgs mmphosis@yahoo.com - 2017-07-07 09:33 -0700
      Re: Targeting both Apple II and IIgs James Davis <JPD.Enterprises@outlook.com> - 2017-07-07 14:03 -0700
  Re: Targeting both Apple II and IIgs James Davis <JPD.Enterprises@outlook.com> - 2017-07-07 14:15 -0700
    Re: Targeting both Apple II and IIgs laseractiveguy@gmail.com - 2017-07-12 05:58 -0700

csiph-web