Re: [libre-riscv-dev] next tasks

Re: [libre-riscv-dev] next tasks

[Hendrik Boom]

On Thu, Feb 20, 2020 at 09:39:21AM +0200, Lauri Kasanen wrote:
> On Wed, 19 Feb 2020 14:14:16 +0000
> Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> 
> > we only have a few months in which to hang together all of the pieces
> > that have been put together, to make a 64-bit 180nm chip.  because
> > we're not doing this in verilog i believe it is reasonably doable, if
> > we take steps to cut "unnecessary" things out i.e. not do too much.
> > chop out L2 cache for example.
> 
> What about the C/C++ simulator/interpreter timeline? It's not a blocker
> for the hw tapeout, but it is a blocker for my work, which probably
> mostly won't make it for the simple Oct tapeout anyway.

What is it you want with this?  An implementation of C/C++ for the new SoC?
Or a simulation of the new SoC instruction set in C/C++?  Would it be good 
enough to have a simulator of the new SoC in any widely available programming 
language?

-- hendrik
> 
> - Lauri
> 
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Luke Kenneth Casson Leighton]

On Thu, Mar 12, 2020 at 2:32 PM Hendrik Boom <hendrik@topoi.pooq.com> wrote:
>
> On Thu, Feb 20, 2020 at 09:39:21AM +0200, Lauri Kasanen wrote:
> > On Wed, 19 Feb 2020 14:14:16 +0000
> > Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> >
> > > we only have a few months in which to hang together all of the pieces
> > > that have been put together, to make a 64-bit 180nm chip.  because
> > > we're not doing this in verilog i believe it is reasonably doable, if
> > > we take steps to cut "unnecessary" things out i.e. not do too much.
> > > chop out L2 cache for example.
> >
> > What about the C/C++ simulator/interpreter timeline? It's not a blocker
> > for the hw tapeout, but it is a blocker for my work, which probably
> > mostly won't make it for the simple Oct tapeout anyway.

correct.  it's on a separate track.

> Or a simulation of the new SoC instruction set in C/C++?

to start from an existing power isa simulator (gem5 for example), that
simulator *happens* to be written in c or more likely c++, therefore
simulated vector and VPU instructions *have* to be written in c / c++.

otherwise we need to create - from scratch - an entire new POWER ISA
cycle-accurate instruction simulator, which would be a genuinely
stupid thing to spend time on given that there are a number of such
simulators in existence already.  including qemu.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Jacob Lifshay]

On Thu, Mar 12, 2020, 07:44 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Thu, Mar 12, 2020 at 2:32 PM Hendrik Boom <hendrik@topoi.pooq.com>
> wrote:
> >
> > On Thu, Feb 20, 2020 at 09:39:21AM +0200, Lauri Kasanen wrote:
> > > On Wed, 19 Feb 2020 14:14:16 +0000
> > > Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > >
> > > > we only have a few months in which to hang together all of the pieces
> > > > that have been put together, to make a 64-bit 180nm chip.  because
> > > > we're not doing this in verilog i believe it is reasonably doable, if
> > > > we take steps to cut "unnecessary" things out i.e. not do too much.
> > > > chop out L2 cache for example.
> > >
> > > What about the C/C++ simulator/interpreter timeline? It's not a blocker
> > > for the hw tapeout, but it is a blocker for my work, which probably
> > > mostly won't make it for the simple Oct tapeout anyway.
>
> correct.  it's on a separate track.
>
> > Or a simulation of the new SoC instruction set in C/C++?
>
> to start from an existing power isa simulator (gem5 for example), that
> simulator *happens* to be written in c or more likely c++, therefore
> simulated vector and VPU instructions *have* to be written in c / c++.
>
> otherwise we need to create - from scratch - an entire new POWER ISA
> cycle-accurate instruction simulator, which would be a genuinely
> stupid thing to spend time on given that there are a number of such
> simulators in existence already.  including qemu.
>

Note that qemu is by-design not a cycle-accurate simulator -- it is
specifically designed to go as fast as possible rather than matching timing
with any particular CPU.

If we decide to create our own simulator, it might be a good idea to write
it in rpython or similar since that has an optimizing JIT trace compiler
that can effectively speed up any interpreter/simulator. That's what's used
to implement PyPy -- it's basically just a python interpreter written in
rpython.

If we decide we don't want rpython, then I would suggest Rust -- I've
already started writing a cycle-accurate CPU simulator to test out my idea
for making a spectre-proof cpu (I stopped since it was taking longer than a
few days):
https://salsa.debian.org/Kazan-team/spectre-resistant-speculative-processor

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Lauri Kasanen]

On Thu, 12 Mar 2020 10:40:16 -0700
Jacob Lifshay <programmerjake@gmail.com> wrote:

> If we decide to create our own simulator, it might be a good idea to write
> it in rpython or similar since that has an optimizing JIT trace compiler
> that can effectively speed up any interpreter/simulator. That's what's used
> to implement PyPy -- it's basically just a python interpreter written in
> rpython.
>
> If we decide we don't want rpython, then I would suggest Rust -- I've
> already started writing a cycle-accurate CPU simulator to test out my idea
> for making a spectre-proof cpu (I stopped since it was taking longer than a
> few days):
> https://salsa.debian.org/Kazan-team/spectre-resistant-speculative-processor

Using a standard language would beat slightly improved speed, for the
usual reasons. The hipster languages have trouble running in many
settings, and we need people to be able to modify the simulator (e.g.
me).

If the simulator was written in hipster language of the week, I may
not even be able to get it running, and it would place a significant
obstacle on my modifying it. More than a decade in C/C++ vs learning an
entirely new language with all its quirks.

It would likely present similar barriers to others who need to modify
it.

(why yes, I have bad experiences with python, ruby, rust, go...)

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Jacob Lifshay]

On Thu, Mar 12, 2020, 23:43 Lauri Kasanen <cand@gmx.com> wrote:

> On Thu, 12 Mar 2020 10:40:16 -0700
> Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > If we decide to create our own simulator, it might be a good idea to
> write
> > it in rpython or similar since that has an optimizing JIT trace compiler
> > that can effectively speed up any interpreter/simulator. That's what's
> used
> > to implement PyPy -- it's basically just a python interpreter written in
> > rpython.
> >
> > If we decide we don't want rpython, then I would suggest Rust -- I've
> > already started writing a cycle-accurate CPU simulator to test out my
> idea
> > for making a spectre-proof cpu (I stopped since it was taking longer
> than a
> > few days):
> >
> https://salsa.debian.org/Kazan-team/spectre-resistant-speculative-processor
>
> Using a standard language would beat slightly improved speed, for the
> usual reasons. The hipster languages have trouble running in many
> settings,


I can agree that rpython sounds like it is probably a pain to set up,
however I've found Rust to be utterly trivial to set up on all Linux
systems I've tried (other than termux -- the distro designed to run on top
of Android -- and even there it was relatively easy):

assuming you've already installed build-essential (needed for the linker),
just install using the one-line command on https://rustup.rs/ then build &
run the project by running:

cargo run -- <args to my program>

or to build and run the program independently from cargo:

cargo build
target/debug/<program-name> <args to my program>

and we need people to be able to modify the simulator (e.g.
> me).
>

Ok. fair point.

I'd recommend learning Rust anyway since Kazan (the graphics driver) is
written in Rust, as well as some of the other code.

Additionally, I find Rust to be just as (or more) expressive as modern C++
and it has additional benefits such as the compiler proving that your code
doesn't have undefined behavior (very handy for when you would have 100kloc
of C++ code that occasionally inexplicably segfaults -- been there), a very
powerful traits system (think C++ template metaprogramming but more
extensible and harder to misuse), and a waay better macro system than C
including stuff like procedural macros (running custom code at compile time
to generate source code).

Also, Rust has a very nice standard build system/package manager (cargo),
it's much better than C and C++'s build system mess.

I found Rust to be relatively easy to understand coming from my background
of >7 years of C++ and C.

If the simulator was written in hipster language of the week, I may
> not even be able to get it running, and it would place a significant
> obstacle on my modifying it. More than a decade in C/C++ vs learning an
> entirely new language with all its quirks.
>
> It would likely present similar barriers to others who need to modify
> it.
>

I had picked rpython and Rust as possible languages since python and rust
are already extensively used in the Libre-SOC codebase.


> (why yes, I have bad experiences with python, ruby, rust, go...)


hope they weren't like my experience with Scala -- never got anything to
build after several hours of trying and the JVM is huge.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Lauri Kasanen]

On Fri, 13 Mar 2020 00:38:31 -0700
Jacob Lifshay <programmerjake@gmail.com> wrote:

I don't want to debate languages, but I have to comment on this:

> assuming you've already installed build-essential (needed for the linker),
> just install using the one-line command on https://rustup.rs/

"Pipe this unknown code from the internet straight to your shell"
That is a huge security hole, and a massively stupid idea. On par with
"install this .exe, it will give you naked pics, I promise".

Please do not advocate for such dangerous practices. Some newbies may
actually do it.

- Lauri

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Jacob Lifshay]

On Fri, Mar 13, 2020, 01:04 Lauri Kasanen <cand@gmx.com> wrote:

> On Fri, 13 Mar 2020 00:38:31 -0700
> Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> I don't want to debate languages, but I have to comment on this:
>
> > assuming you've already installed build-essential (needed for the
> linker),
> > just install using the one-line command on https://rustup.rs/


> "Pipe this unknown code from the internet straight to your shell"
> That is a huge security hole, and a massively stupid idea. On par with
> "install this .exe, it will give you naked pics, I promise".
>

I totally understand where your coming from, however rustup.rs is part of
the official rust project (closely related to Mozilla), see here for
alternative installation options:
https://github.com/rust-lang/rustup#other-installation-methods

it's similar to installing firefox on windows, where you download and run
the executable.

They have a reputation waay better than the average porn website.

>
> Please do not advocate for such dangerous practices. Some newbies may
> actually do it.
>

They're working on better security:
https://github.com/rust-lang/rustup#security

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Luke Kenneth Casson Leighton]

On Fri, Mar 13, 2020 at 8:25 AM Jacob Lifshay <programmerjake@gmail.com> wrote:

> it's similar to installing firefox on windows, where you download and run
> the executable.

which says it all.

as an aside: when i analysed and derived the security requirements
that went into debian's package distribution design, it was
*SEVENTEEN* separate and distinct very specific requirements, any one
of which, if not complied with, completely and utterly destroyed the
security chain of package integrity.

https://github.com/rust-lang/rustup#security

"rustup is secure enough for the non-paranoid, but it still needs
work. rustup performs all downloads over HTTPS, but does not yet
validate signatures of downloads."

here's the good and the bad:

1). bad: it is seriously demeaning to use the phrase "non-paranoid" -
to ACCUSE potential users of rust of "being paranoid".  can i suggest,
jacob, raising that as a severe and high-priority issue with the rust
community to get that removed effective immediate?

2). bad: relying on HTTPS simply makes the website itself a
high-priority hacking target.  HTTPS verifies the *channel*, *not* the
contents.

3). good: at least they recognise that signature validation is critical.

4). bad: unfortunately they don't describe - at all - how they intend
to tackle this, and i can pretty much guarantee that if they haven't
thought about it fully, they *will* get it wrong.  even copying
something like Redhat package distribution or archlinux distribution,
they'll get it wrong.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] Rustup security

[Jacob Lifshay]

On Fri, Mar 13, 2020, 03:13 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Fri, Mar 13, 2020 at 8:25 AM Jacob Lifshay <programmerjake@gmail.com>
> wrote:
>
> > it's similar to installing firefox on windows, where you download and run
> > the executable.
>
> which says it all.
>
> as an aside: when i analysed and derived the security requirements
> that went into debian's package distribution design, it was
> *SEVENTEEN* separate and distinct very specific requirements, any one
> of which, if not complied with, completely and utterly destroyed the
> security chain of package integrity.
>
> https://github.com/rust-lang/rustup#security
>
> "rustup is secure enough for the non-paranoid, but it still needs
> work. rustup performs all downloads over HTTPS, but does not yet
> validate signatures of downloads."
>
> here's the good and the bad:
>
> 1). bad: it is seriously demeaning to use the phrase "non-paranoid" -
> to ACCUSE potential users of rust of "being paranoid".  can i suggest,
> jacob, raising that as a severe and high-priority issue with the rust
> community to get that removed effective immediate?
>

https://github.com/rust-lang/rustup/issues/2262

I don't have permissions to set severity or priority, though I did make a
comment.

>
> 2). bad: relying on HTTPS simply makes the website itself a
> high-priority hacking target.  HTTPS verifies the *channel*, *not* the
> contents.
>

yeah.


> 3). good: at least they recognise that signature validation is critical.
>
> 4). bad: unfortunately they don't describe - at all - how they intend
> to tackle this, and i can pretty much guarantee that if they haven't
> thought about it fully, they *will* get it wrong.  even copying
> something like Redhat package distribution or archlinux distribution,
> they'll get it wrong.
>

They actually do in the list of github issues linked from the above linked
security section:
https://github.com/rust-lang/rustup/issues?q=is%3Aopen+is%3Aissue+label%3Asecurity

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Hendrik Boom]

On Fri, Mar 13, 2020 at 10:13:06AM +0000, Luke Kenneth Casson Leighton wrote:

> 
> 1). bad: it is seriously demeaning to use the phrase "non-paranoid" -
> to ACCUSE potential users of rust of "being paranoid".  can i suggest,
> jacob, raising that as a severe and high-priority issue with the rust
> community to get that removed effective immediate?

The whole point of rust is that its static checking is reassurance for 
the paranoid! 

-- hendrik

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[whygee]

On 2020-03-14 19:13, Hendrik Boom wrote:
> On Fri, Mar 13, 2020 at 10:13:06AM +0000, Luke Kenneth Casson Leighton 
> wrote:
>> 1). bad: it is seriously demeaning to use the phrase "non-paranoid" -
>> to ACCUSE potential users of rust of "being paranoid".  can i suggest,
>> jacob, raising that as a severe and high-priority issue with the rust
>> community to get that removed effective immediate?
> 
> The whole point of rust is that its static checking is reassurance for
> the paranoid!

I think the very existence of this project proves you can never
reassure a paranoid ;-)

> -- hendrik
yg

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Luke Kenneth Casson Leighton]

On Sat, Mar 14, 2020 at 6:23 PM <whygee@f-cpu.org> wrote:

> I think the very existence of this project proves you can never
> reassure a paranoid ;-)

actually, although we can leverage the privacy aspect to attract
motivated developers, the main benefit to end-users is: dramatically
reduced costs due to no royalties and no massive NREs on hard macros
that need to be amortised across the cost of the chip.

the fact that the chip is privacy-respecting is a "side-benefit" for
the majority of people.  the reduced cost is what will hook them.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[whygee]

Hi Luke :-)

and happy Pi day !

On 2020-03-14 19:28, Luke Kenneth Casson Leighton wrote:
> actually, although we can leverage the privacy aspect to attract
> motivated developers, the main benefit to end-users is: dramatically
> reduced costs due to no royalties and no massive NREs on hard macros
> that need to be amortised across the cost of the chip.
> 
> the fact that the chip is privacy-respecting is a "side-benefit" for
> the majority of people.  the reduced cost is what will hook them.

May I remind the rule #1 of sales pitches ?
tell it to the right person ;-)
I'm already sold way before this project started ;-)

> l.
yg

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] benefits of rust

[Jacob Lifshay]

On Sat, Mar 14, 2020, 11:14 Hendrik Boom <hendrik@topoi.pooq.com> wrote:

> On Fri, Mar 13, 2020 at 10:13:06AM +0000, Luke Kenneth Casson Leighton
> wrote:
>
> >
> > 1). bad: it is seriously demeaning to use the phrase "non-paranoid" -
> > to ACCUSE potential users of rust of "being paranoid".  can i suggest,
> > jacob, raising that as a severe and high-priority issue with the rust
> > community to get that removed effective immediate?
>
> The whole point of rust is that its static checking is reassurance for
> the paranoid!
>

while that's true, Rust does have other benefits over languages such as
Python, JavaScript, Java, C#, C, and C++:
speed, consistency (no GC pauses), native execution, low memory usage,
basically nearly all the gotchas are caught by the compiler at compile-time
(unlike C and C++ and, to a lesser extent, other languages) so if it
compiles then it's likely to work, much more powerful type deduction, the
ability to extend the interface of any type, not needing all the special
cases that come with C++ constructors, vastly improved composability,
accessible and easy to use library ecosystem, very friendly community, much
easier to parallelize code, etc.

Static checking is not just for the paranoid, since the checking enables
programmers to make faster programs by using rust's composability to use
faster more complex algorithms that wouldn't be practically feasible to get
correct in a language such as C or Python.

Here's an example where someone was able to use b-trees instead of the
simpler avl trees because rust's checking and composability meant that it
wasn't extremely hard to get correct (as it would have been in C):
http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] benefits of rust

[Hendrik Boom]

On Sat, Mar 14, 2020 at 07:47:45PM -0700, Jacob Lifshay wrote:
> On Sat, Mar 14, 2020, 11:14 Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> 
> > On Fri, Mar 13, 2020 at 10:13:06AM +0000, Luke Kenneth Casson Leighton
> > wrote:
> >
> > >
> > > 1). bad: it is seriously demeaning to use the phrase "non-paranoid" -
> > > to ACCUSE potential users of rust of "being paranoid".  can i suggest,
> > > jacob, raising that as a severe and high-priority issue with the rust
> > > community to get that removed effective immediate?
> >
> > The whole point of rust is that its static checking is reassurance for
> > the paranoid!
> >
> 
> while that's true, Rust does have other benefits over languages such as
> Python, JavaScript, Java, C#, C, and C++:
> speed, consistency (no GC pauses), native execution, low memory usage,
> basically nearly all the gotchas are caught by the compiler at compile-time
> (unlike C and C++ and, to a lesser extent, other languages) so if it
> compiles then it's likely to work, much more powerful type deduction, the
> ability to extend the interface of any type, not needing all the special
> cases that come with C++ constructors, vastly improved composability,
> accessible and easy to use library ecosystem, very friendly community, much
> easier to parallelize code, etc.
> 
> Static checking is not just for the paranoid, since the checking enables
> programmers to make faster programs by using rust's composability to use
> faster more complex algorithms that wouldn't be practically feasible to get
> correct in a language such as C or Python.
> 
> Here's an example where someone was able to use b-trees instead of the
> simpler avl trees because rust's checking and composability meant that it
> wasn't extremely hard to get correct (as it would have been in C):
> http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/

There are many applications that would be better coded in Rust than 
C.

The one drawback I see to Rust is that it doesn't have a 
garbage-collected scope or storage class.  There are programming 
techniques that involve complexly tangled data structure.  Rust is 
not good for such problems.

-- hendrik

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] benefits of rust

[Jacob Lifshay]

On Sat, Mar 14, 2020, 22:18 Hendrik Boom <hendrik@topoi.pooq.com> wrote:

> The one drawback I see to Rust is that it doesn't have a
> garbage-collected scope or storage class.  There are programming
> techniques that involve complexly tangled data structure.  Rust is
> not good for such problems.
>

Rust has support for reference counted smart pointers in the standard
library (Arc (atomic) and Rc (non-atomic)), where those aren't sufficient,
there are libraries for arenas (what I'm using in Kazan for compiler
data-structures (see shader-compiler-ir in the git repo) -- also used in
the rust compiler itself) as well as experimental libraries for full
garbage collection:
see shifgrethor for one of the more interesting GC libraries written by a
core rust contributor:
https://internals.rust-lang.org/t/shifgrethor-garbage-collection-as-a-rust-library/8597

Incidentally, I am also writing a custom garbage collector in Rust for the
next version of my Minecraft-style game engine (Voxels) -- I'm using a 3D
variant of the hashlife algorithm (see wikipedia) which uses a garbage
collector except that the more garbage is kept around the faster it runs
(opposite of most GCs) since it is used to cache computations.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [OT] Minecraft garbage collection

[Hendrik Boom]

On Sat, Mar 14, 2020 at 10:42:55PM -0700, Jacob Lifshay wrote:
> 
> Incidentally, I am also writing a custom garbage collector in Rust for the
> next version of my Minecraft-style game engine (Voxels) -- I'm using a 3D
> variant of the hashlife algorithm (see wikipedia) which uses a garbage
> collector except that the more garbage is kept around the faster it runs
> (opposite of most GCs) since it is used to cache computations.

That looks both interesting and useful!

-- hendrik

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [OT] Minecraft garbage collection

[Jacob Lifshay]

On Sat, Mar 14, 2020, 22:48 Hendrik Boom <hendrik@topoi.pooq.com> wrote:

> On Sat, Mar 14, 2020 at 10:42:55PM -0700, Jacob Lifshay wrote:
> >
> > Incidentally, I am also writing a custom garbage collector in Rust for
> the
> > next version of my Minecraft-style game engine (Voxels) -- I'm using a 3D
> > variant of the hashlife algorithm (see wikipedia) which uses a garbage
> > collector except that the more garbage is kept around the faster it runs
> > (opposite of most GCs) since it is used to cache computations.
>
> That looks both interesting and useful!
>

Thanks!

>
for a early-alpha working version using hashlife (newer than 0.7), see
https://github.com/programmerjake/hashlife3d

I'm currently working (really slowly due to spending most my time on
Libre-SOC) on rewriting the core hashlife algorithm to be multithreaded
using a work-stealing scheduler:
https://github.com/programmerjake/parallel-hashlife-rust

for a decently playable (think Minecraft pre-1.0) old game version written
in C++ -- doesn't use hashlife (the previously mentioned project with
incomprehensible occasional random crashes):
https://github.com/programmerjake/voxels-0.7

compiled versions for Linux, Windows, and Android:
https://github.com/programmerjake/voxels-0.7/releases

Pretty pictures: https://hackaday.io/project/7018/gallery

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [OT] Minecraft garbage collection

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 6:41 AM Jacob Lifshay <programmerjake@gmail.com> wrote:

> Pretty pictures: https://hackaday.io/project/7018/gallery

oooo :)

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [OT] Minecraft garbage collection

[Luke Kenneth Casson Leighton]

On Sun, Mar 15, 2020 at 12:11 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Sun, Mar 15, 2020 at 6:41 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
>
> > Pretty pictures: https://hackaday.io/project/7018/gallery
>
> oooo :)

i thought about this, and realised that, actually, we need a (full) 3D
test application... that *you* understand, jacob.  might as well be
this one.  so we could - in a roundabout way - actually justify at
least using it and, if anything needs fixing, include its improvement
as part of any test suite augmentation.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [OT] Minecraft garbage collection

[Jacob Lifshay]

On Mon, Mar 16, 2020, 06:23 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Sun, Mar 15, 2020 at 12:11 PM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >
> > On Sun, Mar 15, 2020 at 6:41 AM Jacob Lifshay <programmerjake@gmail.com>
> wrote:
> >
> > > Pretty pictures: https://hackaday.io/project/7018/gallery
> >
> > oooo :)
>
> i thought about this, and realised that, actually, we need a (full) 3D
> test application... that *you* understand, jacob.  might as well be
> this one.  so we could - in a roundabout way - actually justify at
> least using it and, if anything needs fixing, include its improvement
> as part of any test suite augmentation.
>

That's a good idea, however, the version (0.7) that is more than just a
simple toy only uses OpenGL [ES] since it predates Vulkan and I stopped
working on it several years ago to work on newer versions, additionally,
the graphics it generates is simple enough that it can run with full
graphics effects on OpenGL 1.5, so it wouldn't stress that many codepaths
in the Vulkan driver.

I think a better idea is to use the Vulkan demo programs written by Sasha
Willems since the programs do some pretty complex graphics stuff with
really fancy shaders:
https://github.com/SaschaWillems/Vulkan

The CPU-side code is actually quite straightforward if you are familiar
with the Vulkan API.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [OT] Minecraft garbage collection

[Luke Kenneth Casson Leighton]

On Mon, Mar 16, 2020 at 4:22 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> That's a good idea, however, the version (0.7) that is more than just a
> simple toy only uses OpenGL [ES] since it predates Vulkan and I stopped
> working on it several years ago to work on newer versions, additionally,
> the graphics it generates is simple enough that it can run with full
> graphics effects on OpenGL 1.5, so it wouldn't stress that many codepaths
> in the Vulkan driver.

awww, i quite liked it :)

> I think a better idea is to use the Vulkan demo programs written by Sasha
> Willems since the programs do some pretty complex graphics stuff with
> really fancy shaders:
> https://github.com/SaschaWillems/Vulkan

niiice.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Immanuel, Yehowshua U]

If we decide we don't want rpython, then I would suggest Rust — I’ve

Like I’ve mentioned before, I’m all for Rust.
If I remember correctly, we’re implementing POWER 3.0 and Gem5 only has support for 2.7(2.7 and 3.0 - wow sounds like Python versions :)…

Anyways, one thing we should strongly consider making the simulator take advantage of multiple cores.

Honestly, we could implement a single cycle CPU in RTL and the compile it into C++ with Verilator.
To me, this seems to be the way to go.

1. Verilator Creates quite speedy cycle accurate C++ models
2. RTL is a really natural way to describe a CPU - duh
3. A single cycle CPU is about 3 - 4 days worth of labor
4. If we did the Single cycle CPU reference simulator in BSV for example, it’d simulate even faster than it would in verilator

I know using an RTL implementation of a CPU to test other RTL implementations seems unatural, but if we’d want to catch errors like pipeline and flushing behaviors in our CPU, then what makes more sense than a single cycle reference?

Also, I’d imagine in the future that we’d want to have speedy unit-testing etc etc, and considering ventilator offers multi-core support, we could see the speedup benefit of throwing our unit tests at a 64 core risen 3990x for example.

@Lauri, Jacob, and Luke - Thoughts and Comments?

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Jacob Lifshay]

On Mon, Mar 16, 2020, 11:30 Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

> Also, I’d imagine in the future that we’d want to have speedy unit-testing
> etc etc, and considering ventilator offers multi-core support, we could see
> the speedup benefit of throwing our unit tests at a 64 core risen 3990x for
> example.
>

I'd be very surprised if it scales that far, that would usually require an
entirely different simulator architecture.

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Luke Kenneth Casson Leighton]

On Monday, March 16, 2020, Immanuel, Yehowshua U <yimmanuel3@gatech.edu>
wrote:

>
> If we decide we don't want rpython, then I would suggest Rust — I’ve
>
> Like I’ve mentioned before, I’m all for Rust.
> If I remember correctly, we’re implementing POWER 3.0 and Gem5 only has
> support for 2.7(2.7 and 3.0 - wow sounds like Python versions :)…


hugh just pointed me today at work by IBM and a university in India which
fixes that.


>
> Anyways, one thing we should strongly consider making the simulator take
> advantage of multiple cores.
>
> Honestly, we could implement a single cycle CPU in RTL and the compile it
> into C++ with Verilator.
> To me, this seems to be the way to go.
>
> 1. Verilator Creates quite speedy cycle accurate C++ models
> 2. RTL is a really natural way to describe a CPU - duh
> 3. A single cycle CPU is about 3 - 4 days worth of labor
> 4. If we did the Single cycle CPU reference simulator in BSV for example,
> it’d simulate even faster than it would in verilator


yes it is a huge advantage of BSV that it actually compiles to an
executable that is 20x faster than verilator.


>
> I know using an RTL implementation of a CPU to test other RTL
> implementations seems unatural, but if we’d want to catch errors like
> pipeline and flushing behaviors in our CPU, then what makes more sense than
> a single cycle reference?


an FPGA test.

this is absolutely essential.

an FPGA test finds parallelism, gate propagation and timing errors that RTL
level simulations simply cannot catch.


> Also, I’d imagine in the future that we’d want to have speedy unit-testing
> etc etc, and considering ventilator offers multi-core support, we could see
> the speedup benefit of throwing our unit tests at a 64 core risen 3990x for
> example.


we have just been offered access to raptorcs POWER9 remote login, so we can
do some unit tests on there.

jacob i think it would be really good to get the algorithmic library into
shape by actually running it on there, and for the unit tests to try all
the different rounding modes exceptions etc.

then when we have that, we can also run the nmigen RTL on the same (fast)
hardware and make sure it covers the same cases.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Luke Kenneth Casson Leighton]

https://github.com/power-gem5/gem5/blob/gem5-experimental/src/arch/power/isa/decoder.isa




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Immanuel, Yehowshua U]

> we have just been offered access to raptorcs POWER9 remote login, so we can
> do some unit tests on there.

Oh - doi.

Run the binaries on an actual POWER CPU for unit testing…

In that case, I have a POWER PC iMac G3 lying around in my bedroom…
Definitely not POWER 3.0 - I think its POWER 2.03… :(

Yehowshua
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Immanuel, Yehowshua U]

> we have just been offered access to raptorcs POWER9 remote login, so we can
> do some unit tests on there.

Wait… I didn’t know we had a raptorcs…

Yehowshua

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Luke Kenneth Casson Leighton]

On Mon, Mar 16, 2020 at 11:12 PM Immanuel, Yehowshua U
<yimmanuel3@gatech.edu> wrote:

> In that case, I have a POWER PC iMac G3 lying around in my bedroom…
> Definitely not POWER 3.0 - I think its POWER 2.03… :(

if it's 64-bit it miiight be useful for running the FP unit tests.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Jacob Lifshay]

On Fri, Mar 13, 2020, 03:13 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> 1). bad: it is seriously demeaning to use the phrase "non-paranoid" -
> to ACCUSE potential users of rust of "being paranoid".  can i suggest,
> jacob, raising that as a severe and high-priority issue with the rust
> community to get that removed effective immediate?
>

Fixed: https://github.com/rust-lang/rustup/pull/2265

Jacob

>
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] next tasks

[Luke Kenneth Casson Leighton]

On Tue, Mar 17, 2020 at 6:23 PM Jacob Lifshay <programmerjake@gmail.com> wrote:

> On Fri, Mar 13, 2020, 03:13 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
>
> > 1). bad: it is seriously demeaning to use the phrase "non-paranoid" -
> > to ACCUSE potential users of rust of "being paranoid".  can i suggest,
> > jacob, raising that as a severe and high-priority issue with the rust
> > community to get that removed effective immediate?
> >
>
> Fixed: https://github.com/rust-lang/rustup/pull/2265

wow that's fantastic, they listened.

l.

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev