[Libre-soc-dev] Introduction

lkcl luke.leighton at gmail.com
Fri Sep 10 19:52:17 BST 2021

On September 10, 2021 5:51:28 PM UTC, Andrey Miroshnikov <andrey at technepisteme.xyz> wrote:

>more interesting languages that existed.
>I've only heard of Algol, Fortran, Ada, Lisp (its many variants),
>(used briefly), but not used them. Even then there were over languages 
>like B, D, F etc.

the BBC Atom had something insanrly obscure, and i remember in.... 1979 a neighbour having a Superbrain with something called APL.

> >started on Ada.
>I guess you have some experience using (or suffering with) it. All I 
>know is that it's difficult to write code that will break during
>in Ada, which is why it's used in aerospace etc.

and as the basis for VHDL, apparently.

>Ah, do you mean formal verification?
>If so, I have used symbiyosis when I was doing Dan Gisselquist's 
>introductory series to Verilog and formal verification 

oh, nice, because we have quite a lot of EUR availabke if you want to go that route.

>I haven't studied the OpenPower spec yet (should I give the 3.0b or
>a read?)

muhahaha only if you want to go blind. it's 1350 pages.

the saner route is "learn by doing", go over Dmitry's excellent "firststeps" tutorial (on the wiki) 

>If there's something I could do to help, perhaps something less
>that wouldn't hinder your progress, let me know. (Luke has mentioned 
>updating the test_isa_caller.py test cases to use "a 'Power ISA test 
>API" instance' (see below).

well there's things that need "morphing" if you know what i mean.  no rush.

> > 
>I look at running this test once gdb compiles.

>> establishes a "Power ISA test API" instance *containing* the expected
> > results... then simply calls the function that kyle's working on 
>Sounds do-able, once I have a better understanding of the file
>(and I do the small admin updates for the wiki), I could start doing

cool.  basically look at teststate.py in soc, which kyle recently created, the static (expected) results should fit with that in some dummy way, so that (see test_core.py) when handed to check_regs it goes, "pffh i can check against that"

>Good rule, I'll stick to it.
>Just one clarification however, if I making the same general change to 
>several files, should I put that under one commit?


>For example after running a few scripts from dev-env-setup, I noticed a
>lack of -j$(nproc) flag in the "make" statements, so the compilation 
>only used one thread (unless the system "make" config has a default I 

i prefer to make the decision explicitly as to whether to overheat my laptop.  if there's a way to make that flexible feel free 

>Seems that disabling HTML view in thunderbird automatically makes the 
>message follow the 80-char line limit, so less to think about for me at
> least.



More information about the Libre-soc-dev mailing list