Re: [cc65] Memory impact of Atari library compile time defines

Hi,

Ullrich von Bassewitz wrote:

> On Thu, Nov 19, 2009 at 11:59:54PM +0100, Christian Grössler wrote:
>>> I cannot really comment on these two. But uppercasing file name string
>>> literals in the source code is not really a problem.
>> Hmm, yes, of course. But what about user input of filenames? If the C
>> code would have to deal with this I think it would have a bigger memory
>> impact.
> 
> If the program reads a filename from the user, it does also need some sort of
> input processing that distinguishes between valid and invalid file name
> characters. There's absolutely no problem in doing a toupper or strupper()
> here. The toupper routine has 16 bytes, plus the call = 19 bytes. This is much
> cheaper than ucase_fn.

I was thinking about portable programs when I wrote it (AFAIR).

My idea was that if someone does what you describe, it's anyway
a program targetted for the Atari. If (s)he gets space problems
(s)he could compile the runtime lib without the UCASE_FILENAME
define.

But if the program should work on Unix or Windows, too, this toupper
call would be bad. (On Windows maybe not so much, since it would
only affect files which are created because of the case insensitivity
of the file system, and the problem would only be cosmetical.)

Of course, one can say that the user should simply enter uppercase
filenames only.

But I thought this solution would be more convenient (for all, users and
programmers, except for those which have a memory problem).


>> I've invented these customizable defines in the Atari library makefile
>> in order to provide a default configuration which works out of the box
>> for most users. ("users" are in this case the developers using cc65,
>> not the "end users" running the program.)
>> But give advanced users a way to do some adjustments.
> 
> Is there anybody who has tweaked these settings before?

I don't know. No one told me at least.

Maybe I look at it too much from the (low-level) developer side :-/

In my opinion, if I build a program and run into problems, but have the
source for the runtime library available, tweaking the runtime library
is not that a big deal.

(I remember modifying the Borland Pascal runtime lib to parse the
command line parameters from 4DOS. 4DOS allowed a command line
of 255 bytes, while plain DOS (COMMAND.COM) only allowed 127
bytes.)


> 
> ucase_fn:
> ---------------------------------------------------------------------------
> str_end:iny                     ; room for terminating zero
>         cpy     #128            ; we only can handle lenght < 128
>         bcs     toolong
> ==>
> str_end:iny                     ; room for terminating zero
>         bmi     toolong         ; we only can handle lenght < 128
> ---------------------------------------------------------------------------
> 
> This is what I found without much searching. I assume there's more.
> 
> I would also remove the check for ATEOL as string terminator. It's a C
> environment, and I cannot think of a case where someone terminates his strings
> with ATEOL.

Thanks. I've changed this.


>> Simpler or smaller? I've tried to make it optimal for any ".if" case.
> 
> I haven't tried it, but always allocating 128 bytes on the stack and combining
> the check & copy loops should save a few bytes. When doing so, you can also
> try to do the uppercasing in the loop and save the call to strupr.

Good idea. I will try to implement this.


> Now, that's an achievement! Removing the file name uppercasing will save half
> a KB. I would really think about that :-)

The ucase_fn code in fact does two things:

	a) uppercasing the string
	b) preprending a device string (like "D1:"), dependent on the
	   current "default" drive

This happened historically somehow and I hope I can split these tasks
when I rework the code.

Removing b) is IMO problematic. Consider the TGI driver names. They
don't have a device descriptor preceeding. We could use e.g. "D1:",
but this would force the drivers always to be loaded from disk 1.
Typically, the drivers probably are on the same disk as the program.

This said, it seems that only SpartaDOS, OS/A, and MyDOS provide the
notion of a "default drive". At least, only these are recognized by
the runtime lib. The other DOSes will use the DEFAULT_DEVICE as set
in the runtime lib Makefile.

To wrap it up, I'll split tasks a) and b) into separate defines, and
let the community (you :-)) decide which ones should be enabled by
default.

regards,
chris
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.