Monday, 2022-08-08

*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC00:18
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc00:19
*** lkcl <lkcl!> has joined #libre-soc00:36
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC00:48
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc00:57
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc01:14
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC03:50
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc03:50
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC04:53
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc04:53
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC05:16
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc05:16
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC06:53
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc06:53
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC08:12
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc08:13
ghostmansd[m]lkcl, I've been thinking of this as "binutils opcode"08:36
ghostmansd[m]From binutils' masks point of view, this is correct08:36
ghostmansd[m]We do have fields.txt parser, right?...08:36
ghostmansd[m]Because without that, it's possible to determine Rc position.08:38
ghostmansd[m]I have been confident that Rc always goes to bit 31.08:38
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC08:54
lkclyes, power_fields.py09:28
lkcl 164 # 1.6.13 XX3-FORM09:29
lkcl 165     |0     |6     |9    |11   |16   |21 |22  |24    |29|30|31 |09:29
lkcl 167     | PO   |     T      |   A |   B |Rc |       XO  |AX|BX|TX |09:29
lkclnot in bit 3109:29
lkcl 225 # 1.6.22 VC-FORM09:30
lkcl 226     |0      |6     |11     |16     |21|22   |31|09:30
lkcl 227     | PO    |  VRT |   VRA |   VRB |Rc|   XO   |09:30
lkclnot in bit 3109:30
lkcland there is one instruction that has "." that does *not* have an Rc field at all09:31
lkclthe masks are actually in VHDL form.  "-" means "don't care"09:32
lkcl0s *must* match09:32
lkcl1s *must* match09:32
lkcltherefore only matching against 1s is unfortunately just plain wrong09:33
ghostmansd[m]Luke, please re-check what I wrote09:46
ghostmansd[m]I stated: from binutils' point of view09:46
ghostmansd[m]I have not yet adopted the code to deal with the whole code we have around09:46
ghostmansd[m]Stating "just plain wrong" is stating the obvious09:46
ghostmansd[m]Yes, I understand the difference between "ignore" and "strict match"09:47
ghostmansd[m]I will check power_fields.py09:47
ghostmansd[m]It is annoying that we became partly dependent on 838, but I _think_ after we emit correct opcodes there's not much to do in binutils09:48
ghostmansd[m]So I will complete this task to degree needed for binutils09:48
ghostmansd[m]I could have avoided the task at all, but it seems we already ignored the overall insn database issue way too long09:50
ghostmansd[m]Having yet another bunch of hacks or a copy-paste is gonna cost us more, so I reluctantly started doing this, and it takes time. Please be patient.09:51
lkcli mention it because i'm really very puzzled as to how matching would even be possible (i mean in binutils) when ignoring 0s09:56
lkclthere is one remote, outside possibility where that might work but i hear what you are saying and leave it with you09:57
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC10:05
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc10:05
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC10:09
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc10:10
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC10:26
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc10:27
ghostmansd[m]Luke, the answer is simple: because the opcode and the mask are different things in binutils. But I think we might have some class which incorporates both opcode and mask... we call it the opcode in our sources and use for both opcode and mask.10:33
ghostmansd[m]Yes, I think I will rename this Opcode class and introduce .opcode and .mask properties.10:34
sadoon[m]Hi guys10:40
sadoon[m]I'm slowly getting back to hobby stuff and I can't for the life of me find a good way to build debian fully from source10:40
sadoon[m]It would be immensely helpful for ppc and ppc64 as well as the libre-soc stuff but damn is the build system a mess10:41
lkclsadoon[m], mornin!10:55
lkclyes, debian building - from scratch - is something that is so rare that nobody has automated it10:56
lkcldebian != gentoo10:56
sadoon[m]therein the problem lies10:56
lkclthey also unfortunately, over the course of 30 years, created circular dependencies10:56
sadoon[m]Gentoo is great but we risk things breaking with updates unlike debian10:57
lkclboth in the base packages (once built) *and* in the build dependencies10:57
markoslkcl, actually it's quite possible10:57
markosI used to do it for one of the companies I worked for years ago10:58
lkcleveryone who tackles it does so with a multi-stage process10:58
markoswe set up multiple installations of mini-buildd10:58
lkclmarkos, yes i remember10:58
markosyou remember genesi with armhf, that was even earlier :)10:58
markosmini-buildd was quite recent actually10:58
sadoon[m]Are there any tools to at least automate most of it?10:58
lkclDescription-en: minimal build daemon - daemon10:58
lkcl Mini-buildd is an easy-to-configure autobuilder and10:59
lkcl repository for deb packages.10:59
markosworks great10:59
sadoon[m]I'll check it out now10:59
markosor at least it did in 2017-1810:59
markoshas a python webui even10:59
markosit's quite modern and much better written than the current official package builders used in Debian itself11:00
markosyou still have to provide it with a base system11:00
markosso as always, the base system is needed for bootstrapping11:00
markoshowever, you can gradually start rebuilding the whole archive if you want11:01
markosyears ago, I did the armhf bootstrapping and it was a pain, mostly because I did native builds -no cross-compilation11:02
markosand it took forever11:02
markosLinaro did ask me to do the arm64 bootstrapping as well11:02
markosbut I kindly refused :D11:02
markosppc64 would be in a much better state plus the hardware is immensely more powerful11:03
sadoon[m]If this is the case then it should be very doable11:15
sadoon[m]Remember that debian keeps full repo archives of sid for ppc and ppc6411:15
sadoon[m]So we do have a full base system for all the toolchains and stuff, it's just that there are not enough maintainers for ppc and ppc64 to have a full stable release on them, which is what we would need11:16
sadoon[m]Gentoo will still be useful for scenarios where the instruction set is different (SVP64 iirc?) and then as discussed before I can try to tool that into debian once we can guarantee it works11:18
markosgentoo is perfect for base system bootstrapping11:19
markosand you can move to full debian package builds once you have that11:19
sadoon[m]yes, but we also need a way to make sbuild (or whatever builder) that we are building specifically for SVP64 somehow11:26
markosto do this properly, we need to get this info in glibc11:27
markosplus arch11:27
markosarch as reported by kernel I mean11:28
markosso that it knows that VSX is disabled11:28
markosthat should be easier once OPF agrees on making VSX optional11:28
sadoon[m]So mini-buildd apparently was last supported on debian 1011:33
sadoon[m]I can't find it in his bullseye repo11:34
sadoon[m]not a huge problem since we can most likely build debian 11 and probably even 12 on a debian 10 system11:36
sadoon[m]but kinda concerning that it's been somewhat abandoned11:36
lkclsadoon[m], markos: there is no EABI for either SFFS nor SVP64.12:04
lkclwe barely get away with the SFFS port on the basis that it's basically "-mnovsx -mnoaltivec"12:04
lkclhowever once that's done then the vision/goal is to make the *SFFS* port the *DEFAULT* for all distros12:04
lkclbut only after re-introducing the dynamic-hwcaps-libc6-runtime-feature-detection12:05
lkcl(that IBM ripped out a few years ago)12:05
markosI know, I was talking of doing things properly, for an initial port it should just be enough to disable vsx/altivec everywhere, but that shouldn't require a *complete* port, just the core system12:05
lkclwhich has remained in intel and comprises 4 levels of hardware12:05
markoswait, what? hwcaps was removed for Power?12:06
lkclmarkos, yes12:06
lkclnot hwcaps12:06
markoseven Arm has it12:06
markosthe runtime detection12:06
lkclthe dynamic-library-runtime-redirection that USED hwcaps12:06
markosbut that's just what ifunc feature was using12:06
markosso no more ifunc for power?12:07
lkclthere used to be the exact same system wich intel has 4 levels of dynamic redirection12:07
lkclIBM submitted patches to rip it out and replace everything with "#ifdef POWER9"12:07
lkclthey've since been told off and finally got the message to stop doing "#ifdef POWER9" and instead to do "#ifdef VSX" and "#ifdef MMA"12:08
lkclsadoon[m], everything and anything involving python 2.7 has been terminated in debian 1112:11
sadoon[m]<lkcl> "sadoon, everything and anything..." <- Yup I noticed it depends on python212:19
ghostmansdWhen I told that CSVs suck, I really forgot that we have fields.text.12:37
ghostmansdCompared to fields.text format, CSVs do indeed look like a gift from God.12:38
*** choozy <choozy!> has joined #libre-soc12:40
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc13:01
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC13:53
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc13:54
ghostmansdlkcl, we pass opint parameter explicitly before parsing the CSV entries ("vanilla" ones, e.g. major.csv et al.)14:06
ghostmansdHowever, the values seem to always be either a decimal or a binary with 0b prefix or a pattern (0/1/- combo).14:07
ghostmansdThat said... Can we drop opint and not keep it in insndb, or there's some obfuscate reason why this is needed?14:08
ghostmansdI'd like to handle this discrepancy in the Opcode class constructor and avoid passing any additional arguments.14:09
lkclghostmansd, i can't precisely recall why i added opint, i think it was to avoid accidental confusion of a mask not containing any "-"s14:11
lkclas in 10000000000000010 as a *mask* would be confused with a decimal number14:11
ghostmansdWell, if we have 0b prefix... Shouldn't it serve it already?14:11
lkclagain: the link to microwatt.14:12
lkclthe numbering is not chosen by us, it is chosen by the microwatt authors when they wrote decode1.vhdl14:12
lkclsome of the numbers are decimal (major.csv)14:12
lkclsome are binary (those i already put 0b in front of)14:12
ghostmansdif op.startswith("0b"):14:13
ghostmansd  op = "2#%s#" % op[2:]14:13
lkclsome are VHDL masks14:13
ghostmansdit seems that our files always use 0b or decimals for non-masks14:13
ghostmansdBut OK, I will extend the code to keep track of the opint14:14
lkclit's been a long time (almost 2 years), i think it's basically opint=True ==> mask format (VHDL mask format)14:15
lkclall of nmigen, VHDL and Verilog all support the same concept in their switch/case statements.14:15
*** choozy <choozy!> has quit IRC14:22
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC16:50
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc16:51
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC17:02
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc17:03
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC17:47
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc17:58
*** tplaten <tplaten!> has joined #libre-soc18:10
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC18:24
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc18:25
*** tplaten <tplaten!> has quit IRC20:51
lkclmarkos, ping, there's a discussion on comp.arch underway about floating-point immediates20:55
lkclcan i ask if you could drop the work-in-progress imdct36 into the git repo so that i can help answer mitch's questions?20:56
markoslkcl, done21:52
*** ghostmansd|2 <ghostmansd|2!> has joined #libre-soc21:57
*** lkcl- <lkcl-!> has joined #libre-soc22:00
openpowerbot[mattermost] <lkcl> markos, thx.  i've restored the original version and moved it to mp3_1_imdct36_float_basicsv.s22:01
openpowerbot[mattermost] <lkcl> so that the original assembler can be kept as a comparative reference22:01
lkcl-markos, thx.  i've restored the original version and moved it to mp3_1_imdct36_float_basicsv.s22:01
openpowerbot[mattermost] <lkcl> we need to be able to say, "and this is by how much percentage SVP64 reduces programs"22:01
lkcl-so that the original assembler can be kept as a comparative reference22:02
lkcl-we need to be able to say, "and this is by how much percentage SVP64 reduces programs"22:02
*** lkcl <lkcl!> has quit IRC22:02
*** ghostmansd <ghostmansd!> has quit IRC22:06
*** ghostmansd[m] <ghostmansd[m]!> has quit IRC22:06
*** ghostmansd[m] <ghostmansd[m]!> has joined #libre-soc22:09
*** hl_ <hl_!~hl@user/hl> has joined #libre-soc22:48
*** midnight_ <midnight_!~midnight@user/midnight> has joined #libre-soc22:50
*** awygle_ <awygle_!~quassel@2604:a880:2:d0::5380:3001> has joined #libre-soc22:51
*** klys_ <klys_!> has joined #libre-soc22:52
*** awygle <awygle!~quassel@2604:a880:2:d0::5380:3001> has quit IRC22:55
*** hl <hl!~hl@user/hl> has quit IRC22:55
*** klys <klys!> has quit IRC22:55
*** midnight <midnight!~midnight@user/midnight> has quit IRC22:55
*** midnight_ is now known as midnight23:04

Generated by 2.17.1 by Marius Gedminas - find it at!