[Coco] 16/32 bit 6809 derivative

[Joel Rees]

2017/09/23 23:31 "Gene Heskett" <gheskett at shentel.net>:
>
> On Saturday 23 September 2017 08:25:26 Joel Rees wrote:
>
> > 2017/09/23 15:26 "Gene Heskett" <gheskett at shentel.net>:
> > > On Friday 22 September 2017 23:54:02 Joel Rees wrote:
> > > > A number of people are designing MMUs for their softcore Cocos.
> > > >
> > > > I'm wondering if I'm the only one who thinks about designing a CPU
> > > > that implements the 6809 instruction set in 16-bit accumulators
> > > > and 32-bit index registers, with a 16-bit instruction set accessed
> > > > by pre-bytes.
> > >
> > > If going to that much trouble Joel,
> >
> > If only I could.
> >
> > I keep wishing I had time to write an emulator for such a CPU.That
> > would likely be my first step.
> >
> > > how about giving it the 6309 instruction set?
> >
> > As fun as that may sound, it doesn't seem like a good idea to me. The
> > 6309 instructions would get in the way of making the design a simple
> > extension of the 6809, and most of the useful functionality would be
> > present in 16/32 bit versions of the 6809's 8/16 bit instructions.
> >
> > If I'm going to go to the trouble of warp the machine code layout to
> > support 6309 instructions, I'd rather warp it a different direction.
> >
> > It might be useful to add some meaningful features, like microcode
> > primitives, including full bit primitives for multiplication and
> > division, caching the stacks, integrating the MMU with the index
> > registers (properly -- not the half-baked gadgetry of the 8086), true
> > DMA channels (instead of blind CPU-blocking block moves), that kind of
> > thing.
>
> I'd have to agree about the bit twiddling. One of the things I've done is
> to look for the compilers version of an 8 bit (or more) shift, which it
> does in a one bit at a time, 16 bits wide loop, and modify the output in
> asm code to do a tfr for the first 8 bits. Measureable worthwhile
> speedup that is.  A true 16 bit "barrel" shifter would be quite handy.

I woulf want to leave the op-code map open for versions that would
include multi-bit shifts, either by microcode or barrel shifter.

I've been looking at division routines and it seems to me that Intel
has led us down another rabbit hole about hardware division and
multiplication.

True bit field extraction also works more efficiently and just as fast
when built on proper primitives. The 6309's single-bit extraction
and manipulation are mostly a waste of that semiconductor real
estate that is claimed (completely unreasonably) to have been
somehow "unavoidably
extra".

> > 6309 support would just get in the way.
> >
> > > In modern 3.3 volt 1500 mhz silicon, it ought to be
> > > able to out coco3 a coco3.
> >
> > Well, yeah. Of course.
> >
> > > I'd love to see something like that running
> > > on a 4GB, 4 core rockchip running at 1.5 GHz on a rock64 card. I
> > > just got 2 of them, and am about to see if I can replace the r-pi-3b
> > > running my biggest lathe, an 11x36 Sheldon thats about 70 years old.
> > > I've not yet booted one, just got them yesterday but oral surgery
> > > interfered.
> >
> > Ouch.
> >
> > > I only need one to run the lathe.
> >
> > Yeah, if I had the money and time to design this thing, it would make
> > a good controller for lathes and such.
>
> No need to. the pi runs linuxcnc, straight from the x86 repo.  Slow video
> of course. The problem with the pi is dropped events, such as keyup etc
> from its own local keyboard. ALL i/o that is not from gpio=spi at 30+
> megabits, comes and goes via an internal usb2 hub, and usb2 silicon
> hasn't the traffic control to manage that properly when the data is
> async from human fingers.
>
> The rockchip propaganda says that data pinhole doesn't exist in its 44$
> card with 4GB of memory.
>
> I wrote some gui code that uses a $20, 100 ppr hand dial from mpja.com to
> replace the mechanical dials that no longer exist on the machine.
> Accuracy down to .0001" per click, but that data comes and goes thru the
> spi interface, and its never made any such mistakes. It Just Works(TM).
> Dial output is a-b in quadrature, no x, so commands are all relative but
> dead accurate.
>
> > But for the foreseeable future, the ARM in your rockchip is going to
> > get you
> > there a darn sight faster.
> >
> > (Darn. :-/ )
> >
> But, I may have to build the kernel due to the internal architecture of
> the rockchip, I still need rt-preempt to run linuxcnc, and I've serious
> doubts the kernel in the iso I've downloaded for it is configured for
> that. On the pi, a 1 millisecond servo-thread has a jitter of only 20
> microseconds when theres no video activity.  Thats excellent for a servo
> thread only machine, and is largely absorbed by the interface card which
> is pretty smart, its a 400k fpga.  Field reprogrammable of course.
>
> > > 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>
> >
> > --
> > Joel Rees
> >
> > http://defining-computers.blogspot.jp/
>
>
> 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>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco