[Libre-soc-dev] Introduction

[lkcl]

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),
>Pascal 
>(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
>runtime 
>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 
>(https://zipcpu.com/tutorial/)

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
>3.0c 
>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
>critical 
>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.


>
> > 
>https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/simulator/test_sim.py;hb=HEAD
>I look at running this test once gdb compiles.

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

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?

yes.

>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 
>guess).

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.

hoorah.

l.