[Coco] 16/32 bit 6809 derivative

Gene Heskett gheskett at shentel.net
Tue Sep 26 09:59:37 EDT 2017


On Tuesday 26 September 2017 02:59:49 Joel Rees wrote:

> Here's what I have in mind for the instruction set and op-code layout:
>
> http://defining-computers.blogspot.jp/2017/09/a-1632-bit-extension-for
>-venerable-6809.html

I would have added a comment, but then saw that it requires a google 
account. google and I parted company several years ago over their 
misshandling of mailing lists, and I have since moved all my mail subs 
to a shentel address since they (the local cable tv people) are my ISP.

My comment was essentially the need for a decent barrel shifter, so that 
long shifts do not linearly expand the time to completion as they are 
used as a 1 bit shift in a loop, repeat n times now.

The c compilers various parts will need massaging to make use of this.  
Do the srcs for all of it as we would package it today using the 
improved stuff we now routinely use, all still exist? rma, rlink, cprep 
and the various c.opts could be merged into a new copt in the process.  
We have too many competing kits for the various jobs of the c compiler 
now, and its too difficult to convince folks they are using broken 
stuffs, like the original c.prep now.

I had a soap box I preached from but got ignored so much I don't preach 
anymore.  Everybody has to make their own bug discoveries it seems, so 
we need a whole new c compiler package which Just Works(TM). One that is 
smart enough to do register swaps for shifts as wide as, or wider than 
the register. That, I think would actually be more at home in a new 
c.opt3 module? 

It does make a testable speed difference in the finished binary right 
now. But in rzsz-3.3.6, it added several hours of handwork on the output 
of cc or cc2 in the middle of a compile.

I had one more thing I was going to do to rzsz, convert the crc calcs 
from byte for byte calls, with all the overhead that represents, to one 
call over the whole buffer or part thereof for the final packet, that 
alone might have sped it up enough it could keep up with a 9600 baud 
link on a 6309.  But by the time I put 3.3.6 out there, I was burned out 
for a while and it never got done. My bad, it should have been done 
then.

Now? Who cares?, we have other, better ways to move a file to/from the 
coco in the form of drivewire. Thank you A.W.

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>


More information about the Coco mailing list