From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-12-09 10:06:14
Hi!
On Mon, Dec 08, 2003 at 11:08:36PM +0100, carlos wrote:
> is ist possible that the underscore will be threated in a way, that it is
> displayed as a thin line instead of a thick one? It's ok for now, but i
> think the thick one looks a little bit strange.
Because it is difficult to have a solution for a cosmetic issue that suits
everybody, and because a custom solution is so easy, I do usually refuse to
make any changes to the character map. In case of your request, someone with a
real TV set instead of a monitor might be glad about the thick line.
But don't despair, there's a simple solution: Using
#pragma charmap()
you can have your own character set translation. Just create a header file
named "mycharset.h", with the line
#pragma charmap (0x5F, 164);
in it. Every time you include this header file, the underline (code 0x5F) in
your source is translated into a thin underline in the target. If you think
you created a really outstanding new character mapping, you can also make a
user contribution from it.
http://www.cc65.org/contribs.php
contains information on how to do this.
> Another thing is, that the sequence
>
> charvar = (unsigned char)(intvar>>8);
>
> will be translated into:
I know. There are lots of statements that do generate suboptimal code. This is
true for "big" C compilers (like gcc), and even more for small ones like cc65.
Adding optimizatons like the one you requested is always a tradeoff, because
it adds code to the compiler backend, which has to be maintained and may
contain bugs. So before adding such code I do usually ask "is it worth it?",
and in your case my answer was "no". Improved code would save 1 byte and 2
cycles for each occurrance found. In an average C source, how many times do
you use above statement? Lets say it's a big program, and shifting a 16 bit
value by 8 is heavily used. Having 100 of these shifts (which means that a
bigger program with 10000 lines will have 1% of the source doing just these
shifts, so it is a real lot) will save just 100 bytes and 200 cycles (may be
more if used in loops). An average program will have 3 or 4 of these shifts,
making such an optimization neglectible.
So while I may add such an optimization some time, I don't see an urgent need
for it. This may of course change if you show me a cool program that would
benefit heavily from it. I have done this in the past (for example for the
plasma demo and for Adam Dunkels Contiki operating system), and I will do so
in the future.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-12-09 10:07:15 CET