Re: A83: Re: Where is everybody?
[Prev][Next][Index][Thread]
Re: A83: Re: Where is everybody?
Not entirely true. You are programming in assembly, not a high level
language. Good code does not have to be readable. It has to work. For
something simple like a simple calculator game, you aren't going to be going
through and using it for anything else. So the faster and smaller it is,
the better.
Take a look at some code by Matthew Shepcar. On the whole, I think he is
the best assembly programmer that I have ever met. His code is optimized on
the design level, and on the implementation. It doesn't matter how good the
actual code is, because if you don't understand the design, then you aren't
going to be able to make sense of the code. If you understand the design,
then the code might make sense, if you study it long enough. But it works,
and is efficient, which is the point.
In some cases, your argument is valid. If you are writing a game for the
Game Boy, where the code needs to be robust and usable for many diverse
levels and such, making extreme optimizations at the source level is not the
best choice. But for something like that were size doesn't matter (at least
on the byte level like the calc), you can get away with it. On the calc,
everything should be as small as possible.
> Yeah, my general opinion on optimization is that it should not get in the
way of succinct,
> readable code. For example, the classic optimization:
>
> ld a,0 ; changes to...
> xor a
>
> ...is cool, because (as long as you know the optimization) it is easy to
understand and
> readable. If an optimization is so obfuscated that it perhaps saves 1
byte, or a few
> T-states and *completely* sacrifices code readability, then to hell with
the optimization.
References: