[Coco] 6809 CC Reg Overflow bit

[Gene Heskett]

On Friday 09 November 2018 13:40:50 William Astle wrote:

> On 2018-11-08 9:54 p.m., James Jones wrote:
> > The 6809 (or 6309) is the best 8/16 bit processor there ever was,
> > but like other processors of the time, the register set is small and
> > non-orthogonal. It might be tough to make a 6809 compiler play "as
> > if", though if you could do it it would very much worthwhile--though
> > to take full advantage of it you'd also want to bring in function
> > prototypes--passing parameters is essentially assignment, and would
> > thus provide more opportunity.
>
> gcc6809 seems to do a pretty good job avoiding all the sign extension
> business. It does so by the simple expedient of doing arithmetic on 8
> bit values using 8 bit operations where possible. It's also pretty
> good at optimizing useless stuff out of the final binary. At least if
> you enable optimization, anyway.
>
> I only mention that because it does show that a compiler can do
> better, even with a 6809 target. Also, even if K&R demands that 8 bit
> operations always be treated as 16 bit operations, even when the
> destination of the result is known to be 8 bits, I would feel
> justified in treating that as a bug in the specification and ignoring
> that provision (you're not going to see a difference in the result if
> you do). That said, dealing with different sizes of operation
> depending on context requires more semantic analysis and, thus, more
> code complexity and more memory usage. As with everything, it's a
> trade-off.

I used to compile only to the assembly output, then hand edit a lot of 
stuff out in my search for speed. The assembler didn't care and I in 
places gained measureable speed. Bit shifting on the 6x09 is a huge time 
sink for instance, there are faster ways. The rzsz-3.36 in our repo's 
has quite a bit of that, and its method of calculating the crc thrown 
out in favor of a table lookup that was at least 200% faster for that 
function at the cost of one 256 byte page of memory to hold those 
values. There are other things that could possibly make it keep up with 
a 9600 baud transfer, but that would have required a major 
re-organization of the code from byte by byte to 256 byte blocks at a 
time, which would get rid of the overhead of 256 subroutine calls (one 
per character) down to one for the block, but I had the xmodem problem 
of what should I do about the final random sized block. I think its a 
solvable problem, but by 3.36 I was about burned out. It was dead 
stable, so I quit while I was 200 cps faster than the original code was.

It might be interesting to try building it with gcc6309 if there is such 
a critter. OTOH that would require a 6309 in your coco. Not everyone is 
up for that.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>