From: Greg Long (cc65_at_maneuveringspeed.com)
Date: 2003-03-05 18:07:51
The Merge sort creates a duplicate array.
(C++ templated attached code utilizing an array class I wrote)
Jiffy clock at 160-162. Yes, I tested it, it's contrary to the usual
endian of low order first. It some situations fast code might be
desirable when reading or setting the clock. here it was not since it's
not in a loop.
I usually use while loops unless it's known that you want the code to
execute at least once, regardless. Either way seems to be generally
considered acceptable, but I can understand why a guy might have
preference to do-while over while since the code there DOES get executed
at least once.
\n\r - scrolling is the culprit it turns out - and I guess this is a
known issue.
-----Original Message-----
From: owner-cc65_at_musoftware.de [mailto:owner-cc65_at_musoftware.de] On
Behalf Of Spiro Trikaliotis
Sent: Wednesday, March 05, 2003 7:57 AM
To: cc65_at_musoftware.de
Subject: Re: [cc65] Finished product: FAST ShellSort demo for c64
(working :) ) - feedback?
Hello,
adding to what Uz said:
Greg Long wrote:
> The Merge and Quick sort algorithms
> are faster, but waste memory...up to twice the ammount of the original
> array.
Well, where do they waste memory? In the needed stack size, or
elsewhere?
> (Now how do I overload the < and > operators in C?)
You can't. Overloading in general and overloading built-in operations in
particular are C++-specific extensions not available to C.
> Known bugs:
> -----------
> 1) cprintf does not appear to work properly : replace \r with \n and
> watch the results.
MV already told you what you have to do: Use \r\n instead.
> //Code below
> void stopwatch_reset();
[...]
> unsigned long stopwatch();
[...]
> int main()
Although not really necessary, I suggest using a void parameter instead
of an empty parameter list. In C++, this is the same, but it is not in
C. In C, it means the function can take any parameter, which seems not
to be the thing you meant, did you?
> //bank out BASIC interpreter
> a = PEEK(1);
> POKE(1,a&254);
I rather would code it something like:
unsigned char *pP6510IO = 1;
and then
*pP6510IO &= 0xFE;
This looks much more "C-like" (or "C++-like") to me.
> //stores # of seconds in locations 1020-1021 POKEW(1020,secs);
Here, something similar like above applies.
> //re-enable BASIC interpreter
> a = PEEK(1);
> POKE(1,a|1);
*pP6510IO |= 0x01;
> unsigned long stopwatch()
> {
> unsigned long sw_time = 0;
>
> sw_time += ((unsigned long)PEEK(160)) * 0x10000;
> sw_time += ((unsigned long)PEEK(161)) * 0x100;
> sw_time += (unsigned long)PEEK(162);
>
> return sw_time;
> }
Is the counter really in this order (160 = high byte, 162 = low byte)?
If yes, what about:
unsigned char *pTimer = 160;
sw_time = (((unsigned long)pTimer[0]) << 16)
| (((unsigned long)pTimer[1]) << 8)
| pTimer[2];
On many architectures, this results in much faster code. I'm not sure
about CC65 (haven't tested it).
If the counter were in the order 160 = low byte, 162 = high byte, I even
suggest:
unsigned long *pTimer = 160;
sw_time = (*pTimer) & 0xFFFFFFl;
> char quit=0;
>
> while(!quit)
[...]
Since the condition is true on first invocation, I would suggest
rewriting the loop to
char quit = 0;
do {
...
} while (!quit);
This way, it is more understandable what your intention was.
Spiro.
----------------------------------------------------------------------
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-03-05 18:08:39 CET