[Libre-soc-dev] Introduction

[Andrey Miroshnikov]

On 10/09/2021 17:55, Kyle Lehman wrote:
> 
> As for weird language stuff, there was the granddad known as ALGOL for 
> block style languages which lead to Pascal and everything else.  Wasn't 
> bad to use it all, in fact it had a couple nice features IIRC while 
> using it.  What blew me away was actually running across it again being 
> used on a Unisys mainframe in the late '90s.  Before that, I always 
> thought of it as a historical and intellectual curiosity. 
Programming languages have an interesting history. Last year (and still 
a little) I had a fad over C (even checked the C99 spec in tandem while 
programming to check which functions are available in the standard 
libraries). However now I realise there's a deeper history, and even 
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.

Also there are tons of systems retained from decades ago, which is why 
Fortran also pops up in places like finance (if I remember correctly). 
On the one hand it lets the language survive, on the other the code will 
eventually become so complex that re-write is the only option.

 >thought of it as a historical and intellectual curiosity.  Don't get me
 >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.

> Nowadays I don't envy compiler writers.  It takes a special kind of 
> person to create a modern C++20 AST.
Understanding and using C++ well requires a special kind person too!
There are probably thousands of features in cpp that as an electronics 
guy I have no idea about. With each release they also seem to dig a 
deeper hole, patching more and more on top of the old.
Inheritance and namespaces are probably the fanciest terms I know and 
actually understand haha


>> The work Kyle is doing, is that under bug 686, create Power ISA test API?
> 
> Yeah.  Fun stuff, determining what is "100% correct".
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/)

I haven't studied the OpenPower spec yet (should I give the 3.0b or 3.0c 
a read?)
However I have looked at the RISCV ISA a few years ago if that helps 
(the first volume, was pretty straightforward).

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


On 10/09/2021 18:02, Luke Kenneth Casson Leighton wrote:
 > TL Lim is sponsoring someone to reverse-engineer the qualcomm 3G/LTE 
modem
 > used in the pinephone.  they've been spectacularly successful.
Interesting, thanks for the info, gotta add their RSS feed to keep up 
with them.

 > seaside road trip!
Yes, there are some wonderful sites over here (although I'd avoid 
Hunstanton if you actually want to swim during the rare hot day, there 
are some smaller beaches with fewer tourists).

 >> Says here modula-2 is based on pascal:
 >> https://www.modula2.org/reference/index.php
 >
 > yes. we were taught it so as to avoid us ending up getting hired
 > away from completing our degree, as happened so frequently
 > that Imperial College Dept. of Computing stopped using c as
 > the teaching language.  so, we learned it on our own time.
Oh, the trope of the computer science student leaving for high-paid 
industry jobs? Why does that not surprise me...

Bristol taught us (electronics students) Scratch (not really a language, 
but was there so that those who never programmed before uni would get 
used to the general concepts, I would've selected Basic to be honest), 
Java, Python, C.


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

 > we've used it in the past to cross-run the ISACaller simulator 
against qemu, to
 > verify certain instructions.  ironically, we found bugs in qemu.
Nice! And that's why open-source development has its advantages.

 > the other necessary task - and it's quite a big one that, really, 
everyone
 > should pitch in with - is to convert all test_isa_caller.py tests over to
 > "expected" form.  each unit test, instead of explicitly calling
 > self.assertEqual(),
 > 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.


 > the rule is:
 >
 >     if you are tempted to use the word 'and' in the - well-written - 
commit
 >     message, it's not a single-purpose commit.  split it.
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 
guess).

 >> Also, some questions on formatting email. Should I limit my response to
 >> 80 chars per line?
 >
 > if replying ends up being converted such that a single paragraph has
 > one "> " in front of it (forcing the writer to do extra work i.e. 
split it
 > manually a few words at a time) rather than the 30-year-established 
standard
 > practice of one "> " per line, then yes, definitely.

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.



Andrey