[libre-riscv-dev] Introducing Myself

[Samuel Falvo II]

On Wed, Jun 5, 2019 at 12:41 PM <whygee at f-cpu.org> wrote:
> it would be interesting to know more about those who don't post often
> :-)

In the interest of completeness,

I'm working on the Kestrel Computer Project, and more specifically, on
the Kestrel-3 incarnation of it.  My vision for this computer is to
target retro-computing enthusiasts who wants something newer than the
old C64, Atari, or Amiga platforms, but who explicitly do not want to
recreate the current PC-compatible user experience.  This is something
I've dubbed "neo-retro".  It is explicitly not intended to compete
with off-the-shelf PC solutions at running Linux, BSD, etc.  OTOH, if
someone wants to port these OSes, I'm not opposed.

I'm relatively new to the libre-riscv project, having been tugged in
its direction by communications with Luke on the official RISC-V
mailing lists.  Although we have differing opinions on some things,
the vast majority of issues relevant to the libre RISC-V community are
something we both agree upon, including the sensation of being locked
out of the ostensibly "open" approach RISC-V is evolving.  From that
common understanding came mutual interest in each other's projects.
It turns out that my Kestrel-3 project's processor was a candidate for
consideration as an I/O coprocessor, and I was/am interested in
libre-riscv as a possible candidate to offer GHz (or, at least close
to it) performance to future Kestrel-3 users in the form of a CPU
upgrade card.  Others have proposed making a future Kestrel design
that is EOMA68 compatible, but I dismissed the idea because I lack the
production facilities to enable that degree of integration.[1]

Well, over time, I'm afraid that my processor's scope has crept
somewhat.[2][3]  Now that I'm learning about out-of-order techniques
and possibilities it enables, I've been slowly incorporating what I've
been learning into the KCP53000B design.[4]  Where once I predicted
about 25% performance enhancement over my 53000 design, I'm now
speculating that *some* types of programs can see as much as 100% to
400% performance enhancement, depending entirely on how many
functional units I can fit into the design.  I'm not sure if this new
design will be simple enough to work as a cycle-accurate I/O
coprocessor anymore.  But, even if not, I'm grateful for Luke, et. al.
letting me share and engage in the knowledge and I'm hoping I can
contribute back in other ways.  Perhaps I already have and just don't
know it yet.  ;)

________
1.  Fun fact: I had not realized that Luke was the motivating force
behind EOMA68 as well.  Small world!
2.  But only somewhat!  I promise!
3.  I use lots of footnotes.  Sorry.
4.  Because of this, I've been thinking of rebranding it the KCP53010,
just as the 68010 followed the 68000.  This means that my original
plans for the 53010 will be bumped to the 53020 instead.


--
Samuel A. Falvo II