[Libre-soc-dev] video assembler

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue May 11 13:23:51 BST 2021


On Tuesday, May 11, 2021, Lauri Kasanen <cand at gmx.com> wrote:

>
> Does it at least count the sub-steps separately? So they can be divided
> by say 8, for an 8-parallel cpu. After all that's the point of simple-v,
> N of these happen at the same time in parallel. Without that there'd be
> no point at all to write anything at this point.


this i would consider to be a false objection: in english, "cart before the
horse".  with no unit tests we cannot even begin to know where the areas
are to make improvements.

plus, the whole point of SV is not to require software writers to have to
completely redesign an algorithm for hardware with different speed /
Internal architecture.

my biggest concern is that by not starting we have nothing at all by the
Grant deadline which is only around six months away.

we can create any number of reasons why this work should not be started.
no compiler no binutils no simulator no full optimised SVP64 implementation
no cycle accurate simulator no HDL no FPGA card no OS Support no app
support.

we have to cut through that and begin somewhere, before it is too late and
we lose the funding.


> Another issue that came up is getting the C baseline extracted if it
> happens to call any helpers in libgcc. That needs either linking, or
> manually appending the asm of those functions, and everything they
> call...


yep, this is pretty low level, and what you suggest has been done before,
implementing extreme subsets of POSIX for example, or using (or writing) a
Real Time OS.

initially we are even below *that* point.  what i would like to see is the
absolute most basic possible inner loops, maximum of say 20 to 50
instructions, one function (one asm file) which gives at least a unit test
of some type.

once those inner loops are done as demos they achieve two things:

1) they act as more complex unit tests, that help ensure the HDL and
simulator is functional where needed

2) they help show where things should go for the next phase (full
algorithms)

to give you some context, Lauri: the largest unit test currently ever run
is only 7 instructions.  "only" 20 opcodes would be a *200*% increase on
that.

so the question is: would you be ok to do *really* basic unit tests, that
*at a later date* may be adopted and adapted to create the full
algorithm(s)?  i can make it easier to set up.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


More information about the Libre-soc-dev mailing list