Tuesday, 2021-02-09

soreardo you expect to get more units in the field than there are currently, say, m68k or ia64 systems?00:00
programmerjake[mdepends on how many m68k or ia64 systems there are, we're expecting at least around 100k units otherwise we wouldn't make enough to recoup costs00:03
programmerjake[mhoping for >500k00:03
lxolet's not aim for any less than total world domination ;-)00:04
programmerjake[myeah, but I doubt that will happen right away...00:05
rsc>500k systems without mainstream OS support sounds IMHO ambitious if there aren't large businesses using them for their own purposes.00:05
programmerjake[mworld domination takes time :)00:05
programmerjake[mhence why we're trying to get mainstream powerpc64le os support00:06
soreargiven what I've seen in the riscv world anything more than 1k for a SBC seems optimistic, but I hope you're right00:07
programmerjake[miirc we already have some customers lined up for at least 50k units00:07
jn__if the Raptor TalosBook with Libre-SoC comes out in five years, i'll buy it :)00:08
programmerjake[msorear: remember, SBCs are only one of many applications for Libre-SOC00:10
segherlxo: no, sorry00:35
segheri do not know if it will make sense at all eventually00:36
segherwe do *not* want to fragment what modes we have, etc.00:36
segherwe already have way too much exponential complexity; i am trying to get rid of that, not add more00:36
segher(and you *need* literals, in the debug info)00:37
lxosegher, err, it doesn't look like I was clear on what the patch does00:41
lxo-    for (int i = info->first_fp_reg_save; i < 64; i++)00:42
lxo+    for (int i = info->first_fp_reg_save; i < LAST_FPR_REGNO + 1; i++)00:42
lxois this not a desirable change?  we already use this for altivec regs, why not gpr, fpr?00:45
segheri renumbered the registers not too long ago so that the numbering makes sense00:46
segher0..31 GPRs, 32..63 FPRs, 64..95 VRs, 100..107 CR fields00:47
lxoin my book, using symbolic, mnemonic names for constants is superior software engineering than literals00:47
programmerjake[m+1 for symbolic names00:48
segheryou see the raw numbers in debug dumps00:48
lxoyeah, we do, so what?00:49
segherand it is important for performance to have those first three ordered like that00:49
programmerjake[mdebug dumpers can be improved to show symbolic names...00:49
lxoit's not like I'm trying to hide the numbers, I'm just trying to make them meaningful00:49
segherlxo: i look at those dumps all day every day, and there are more people doing that00:49
segherand GCC *does* print the symbolic names as well00:49
segherGPR0 is printed as 000:50
lxoplease listen00:50
segherFPR0 is printed as 000:50
lxoI'm not talking about outputs00:50
lxoI'm talking about the code in gcc/config/rs6000/00:50
segherso we need the raw numbers to be readable00:50
lxowhen you see a 29 or a 62 in there, that's not meaningful00:51
segherthey also cannot change easily, because we have to translate them (in a few ways!) for the debug info00:51
sorearwhat if ... octal or hex00:51
lxowhen you see a 32 or 64, is that a FPR or VEC register, or is it one past the end of GPR or FPR?00:51
seghersorear: they are always decimal00:51
segher32 is an FPR00:51
sorearthat seems like the problem.00:51
segher64 is VR00:51
segherit cannot be one past00:51
lxosegher, yeah, until they're used as the boundary to end the loop over GPRs and FPRs, respectively00:52
segherwe never have numbers that do not denote a register00:52
lxosee above00:52
segheryes, that uses +1 for a reason00:52
lxoI put the +1 there00:52
lxothat's part of the patch00:53
seghercurrent code uses IN_RANGE00:53
segherwhich is inclusive00:53
lxosince when?00:53
seghersince always00:53
lxothe patch is from last week's codebase00:53
lxoso, no, you're mistaken about what the code uses right now.  at least in that place00:54
lxoand there are lots of such hunks in the patch00:54
segherthere is nothing else that uses LAST_FPR_REGNO00:54
lxoyou understand what '-' and '+' mean in a patch, right?00:54
lxothe line with the literal 64 is what was there before I changed it to use some meaningful symbolic constant00:55
segherno need tto be insulting, lol00:55
segherand it is not nmore meaningful00:55
segherthere are 32 FPRs.  this has been part of the architecture since forever00:56
segheri also do not write "c" when i mean light speed.  i just write "1"00:56
lxoso which FPR is 64 again?00:56
programmerjake[mwell, with SimpleV, there are 128 fprs00:56
segherthere is no 6400:56
segherthis loops to 63 as last00:56
segheri do not write 63 + 100:56
lxowant me to post the line that has 64 in there again so you'll see it?00:56
segherbecause that is just dumb00:56
programmerjake[mfuture versions of SimpleV may expand the number of registers to 256 or 51200:58
segherand that is very problematic00:58
segherbut, bedtime.  cyal00:59
lxoprogrammerjake[m, that's not really relevant for purposes of the patch.  I'm just introducing uses of mnemonic constants instead of ambiguous literals00:59
programmerjake[mlxo: it's relevant to not getting used to gcc's internal register numbers remaining fixed...01:00
lxotrue, but we don't need those extra registers to be in the middle of preexisting files01:01
lxolike, we *could* add fr32..fr127 right after r32..r12701:03
lxoit would prevent vectors from crossing the 31/32 boundary, but that's probably not a big deal01:03
programmerjake[myup, but that probably makes allocating ranges more complex01:03
lkclsegher: we\re extending scalar INT, FP and CRs all to 128 entries.  this is a bare minimum for a 3D GPU.01:05
lxor31 is usually not available for allocation anyway, so it's no big deal there.  for FP, it could be useful to cross that boundary, but not critical.  cr7/cr8 might be the most critical boundary01:06
lkclnot crossing over from 31/32 might actually be cleaner, but also just a quirk that's covered by reg allocation01:08
programmerjake[mhmm, in the code I've seen, r31 is rarely used, so it should be free most the time01:09
lxoremember that gcc ra allocates to *contiguous* registers01:09
programmerjake[mmost code doesn't need r31 since the stack frame isn't variable-sized01:10
programmerjake[mI personally think that we should just renumber gcc's internals -- producing worse code because of sw bickering seems like the wrong direction...01:12
lxoI agree, and that's what I implemented.  that got me to notice the literals, even01:13
lxobut it's not the end of the world if we get pushback from upstream on these grounds01:13
programmerjake[mI would even go as far as replacing the register number type with an enum...01:16
lxoit might even be sensible to leave the "legacy" registers for use as scalars, with shorter opcodes, and use the extended registers primarily for vectors.  this break at 31/32 wouldn't likely only make for significant differences in corner cases and tests intended to trigger it01:16
programmerjake[menum: though that could be a lot of work01:17
lxousing enum as array index is iffy01:17
programmerjake[mat this point, with the `#define`s and the integer type, sounds like a poor-man's enum to me01:19
lxowhat define?01:20
lxothere's a define_constant in rs6000.md that introduces the constants I'm talking about01:20
lxoin C code, they become #defines indeed, but they have integral types, not enum types, so they can be used to index arrays, which GCC does a lot with internal register numbers01:21
programmerjake[mif it's a const instead of a define, it's still essentially the same01:22
lxo   (LAST_FPR_REGNO159)01:22
programmerjake[mdon't see why you can't index arrays with C-style enums...01:22
programmerjake[menum class ... harder01:22
lxouhh, I was pretty sure there was some warning or error against using an enum constant as an array index, but maybe I'm mistaken01:25
programmerjake[mnothing with -Wall01:25
lxothere's nothing fundamentally wrong with it, I just thought there was some rule against it01:26
lxomaybe it's just some style thing somewhere01:26
programmerjake[mC enums are pretty close to typedef int E, so I see no issue01:26
programmerjake[mstackoverflow seems to think it's fine: https://stackoverflow.com/a/40426301:29
lxoI'm pretty sure there's some pitfall there, involving C or C++, but I unfortunately can't recall what it is01:32
lxomaybe it has to do with -fshort-enum, which is enabled by default in some ABIs01:33
programmerjake[mthat's what `enum E : int {` fixes01:33
lxoyeah, but that's C++ only01:34
programmerjake[misn't gcc compiled in C++?01:34
lxomost of it, yeah01:37
programmerjake[malso, even if short-enum is enabled, all you need is to add another enumerant: `LAST = 0xFFFFFFFFL`01:37
awyglelkcl: if you still want me to work on the partition thing, I'm game01:40
lxoprogrammerjake[m, anyway...  the bits that define symbolic names for registers, so that they can be used in both C/C++ sources and the LISP-ish ones, are in LISP-ish machine descriptions01:41
programmerjake[mah, ok. that might make it harder, but it still may be a worthy goal for sometime, not now01:43
programmerjake[mtoo bad .md is usually interpreted as markdown...01:43
programmerjake[mexcept on libre-soc's wiki, where .mdwn must be used, because ikiwiki01:44
lxoI think gcc already used .md files before aaron was even born01:50
programmerjake[myeah, hence why I didn't say: too bad gcc devs didn't check for well-known file formats before picking file extensions01:52
programmerjake[mthough it might be a good idea to rename them if it doesn't cause too much trouble...01:52
programmerjake[m.mdes anyone?01:53
programmerjake[mor is gcc trying to still build on ms-dos?01:54
lxonah, this sort of pointless cosmetic change just makes it harder to merge changes across branches.  not going to happen.  we still use .c for souce files that used to be in C01:54
lxoI haven't heard of DJ's giving up on DJGPP01:55
lxome, I like .mdwn :-)01:56
programmerjake[myeah, but isn't that mostly a cross-compiler? and it requires non 8.3 file name support?01:56
programmerjake[mme, i like .md since that's default in most editors01:57
lxoI'm pretty sure djgpp was native, but I don't think I've ever used it01:57
programmerjake[mi did, wrote a sw 3d renderer using vesa vbe with it01:58
lxowhen I open a GCC .md file with the one true editor ;-) it selects lisp mode01:58
programmerjake[mprobably your editor uses heuristics to detect it01:59
lxoby the time I came across GNU, I switched over to it (on Unix systems), and didn't really look back to DOS02:00
lxo(add-auto-mode "\\.md\\'" 'lisp-mode) ;; <-- heuristics.  I had no recollection of having added this bit to my .emacs.  it's been a while :-)02:01
programmerjake[mi mostly used dos for raw hw access02:01
lxoI used DOS between 1985 and 199102:02
lxoI wrote a bunch of TSR programs like keyboard accelerators and accent-prefix combiners for various "standards" that existed back then02:04
programmerjake[mone true editor: obligatory xkcd reference: https://xkcd.com/378/02:05
lxo:-)  I often make fun when others label emacs as an editor.  it's an heresy.  vi is an editor.  emacs is a development environment, almost an operating system02:06
programmerjake[mI used dos well past then, mostly switching to linux by 201202:07
programmerjake[mthough it was mostly dos from in win xp02:08
lxoI've used gnu since 1991, but only started using gnu/linux on 199602:08
lxoI managed to avoid windows :-)02:08
programmerjake[mi started using linux when I got a dual-socket pentium 4 with 64-bit support, didn't have a 64-bit version of windows, so installed linux02:09
programmerjake[mthough I did use it some before then02:10
lxoI haven't used linux for 13 years02:11
programmerjake[monly gnu/linux? ;)02:11
lxono, I started using linux-libre then02:12
programmerjake[mah, well I still count that as a linux variant02:12
lxoI wish people who referred to the operating system as linux would agree with that kind of perspective and call it gnu02:14
programmerjake[mnot to be confused with gnu hurd...02:14
lxono, that's another gnu kernel02:15
programmerjake[mwell, we live in the world of often-ambiguous overlapping terminology... earlier today, for Rust's SIMD working group, we agreed that element/lane are equivalent02:17
lxopoint is that people who will deny to their graves that they use a gnu system have no whims whatsoever admitting that it's a unix system02:18
programmerjake[mbut lkcl thinks that lanes are nearly antithetical to SimpleV and elements are correct...02:18
programmerjake[mI won't deny that it's gnu, but I still use the commonly accepted alias "linux" for gnu/linux02:19
lxoyou're entitled to choose which ideology you wish to endorse and promote02:20
lxo(or lack thereof)02:20
programmerjake[mthough that leads to confusion when describing android ... bionic/linux?02:20
lxothe operating system name is android02:21
programmerjake[mwait, i know, ad-distribution-platform/linux02:21
lxolinux was initially intended as a kernel to work with gnu userland, but it was later adopted as the kernel underneath android as well02:22
lxoearlier, it seems that it was conceived of as a full operating system, but that was abandoned in favor of developing just a kernel02:23
programmerjake[mhmm, didn't know that02:23
programmerjake[mwell, debian does/did also have gnu/kfreebsd02:24
lxoand there was a distribution of gnu with the opensolaris kernel, and IIRC there was even a gnu/darwin one02:26
lxoearly on, linus often compared the kernel and his plans with gnu and minix, but linux is how he names the tarballs of the kernel he started02:27
programmerjake[mi think there's even a few more x/linux OSes out there02:28
lxoI'm curious whether F*csia :-) will have linux as the kernel02:30
lxohttps://mirrors.edge.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01 is quite enlightening to read and get a perspective of how things looked before history started being rewritten02:32
lxothis was from a time when linux was anti-commercial (thus non-free)02:34
programmerjake[miirc fuschia has it's own kernel02:39
lxothat's my impression as well02:41
lxofuschia is an interesting way to spell it.  it sounds like fusca, the way the volkswagen beetle is called in brazil02:41
lxothe original beetle02:42
lxoI still prefer the f*chsia expletive ;-)02:42
programmerjake[midk, it's named after a color, most of the weird and wonderful color names are incomprehensible to me...02:43
programmerjake[mif we're taking about weird OSes, I'm a little partial to Redox OS: https://www.redox-os.org/02:46
programmerjake[mwas daydreaming with cole a while ago about having kazan ported to Redox, first accelerated 3D graphics for Redox would be Libre-SOC :)02:47
sorearit's Fuchsia, named after a mr. Fuchs, normal german name and dictionary word02:48
programmerjake[mah, ok02:48
programmerjake[mone of the coal tar chemists of the 1800s I presume?02:49
lxofuchsia also names a flower, whose typical color is referred by the same name02:50
sorearLeonhart Fuchs (German: [ˈfʊks]; 17 January 1501 – 10 May 1566), sometimes spelled Leonhard Fuchs,[1]02:50
sorearplausible but no02:50
programmerjake[mwow, much earlier than expected!02:50
lxosorear, is this a fact, that fuchsia is named after a mr fuchs?02:52
lxofuchsia the operating system, I mean02:52
sorearfuchs (man) -> fuchsia (flower) -> fuchsia (color) -> fuchsia (OS)02:52
sorearhttps://fuchsia.googlesource.com/fuchsia/ "Pink + Purple == Fuchsia"02:53
sorearpresumably the man was named after fuchs (fox)02:54
programmerjake[mfuchs (man) -> fuchsia (flower) -> fuchsine (chemical) / fuchsia (color) -> fuchsia (OS)02:54
programmerjake[mI *knew* there was some 1800s chemist involved...02:55
lkclprogrammerjake[m, i don't.  they're also interchangeable terminology.  please do try not to assert things i haven't said!10:33
lkclawygle, superb, yes please10:33
lkclcould you send me an ssh key by email, to lkcl@lkcl.net, and an appropriate email address you're happy to have in the bugtracker (i can set up a redirect through libre-soc.org if you prefer, i did that for lxo)10:38
programmerjake[mlanes/elements: ok, well it had seemed that way to me before...10:39
programmerjake[mI think what had happened is I was using the term lanes which had somehow confused lkcl into thinking I meant we should implement a x86-style SIMD instruction set or something, that was all cleared up several months ago when it happened. sorry lkcl, didn't mean to put words into your mouth10:57
programmerjake[mdidn't see when it happened after some quick searching, so just going off my memory10:58
lkclthe confusion probably stems from a long time ago when we were discussing traditional vector architectures11:00
lkclgiven that we're now doing predicated SIMD back-ends the lines are blurred and the terminology - wording used - is irrelevant/interchangeable11:01
programmerjake[mok, sounds good!11:02
lkclwhere the distinction _will_ be needed is when multi-issue comes into play11:02
lkclbecause, there, if you have QTY 2 4-wide SIMD back-ends, elements 0 and 4 will be allocated to Lane ZERO of SIMD-FU-1 and Lane ZERO of SIMD-FU-2 respectively11:03
lkclelements 1 and 3 to lane ONE of SIMD-FU-1 and SIMD-FU-211:03
lkcletc. etc11:03
programmerjake[mhmm, for reduction of confusion I think we should have lanes/elements be exactly equivalent at ISA and SW levels11:03
lkclbut a single-issue in-order system, or a programmer, won't know and won't care.11:03
lkclthat would make it impossible to talk, in hardware terms, about even the existence of SIMD Function Unit 1 and 2.11:04
lkclfrom a programmer perspective, there's no difference, they don't care and shouldn't have to care.  at all.11:04
lkclfrom a *programmer* perspective, even the *existence* of the two SIMD function units in an OoO microarchitecture is entirely transparent11:05
lkclso from a *programming* perspective, the fact that the Rust subcommittee on SIMD has determined that there is no difference between Lanes and Elements is a perfectly valid perspective11:06
programmerjake[mthe only way a programmer would care is execution time11:06
lkclbut from a *hardware* perspective it absolutely is *not* correct to conflate the two.11:06
lkclboth perspectives are however perfectly correct... *in their context*11:07
programmerjake[mok, though I think referring to lanes/elements as equivalent words even in a hw context can be helpful, to refer to lane/element 1 of a simd alu, you'd write element 1 of simd alu #1, to refer to lane/element 1 of the ISA-level instruction, you'd write element 1 of ISA-level instruction. or something...11:10
programmerjake[manyway, gtg, time for me to sleep11:11
segherlxo: r31 *is* available for allocation12:41
segherand changing that specific code to not use the fixed numbers is completely wrong: it is ABI!12:42
segherthis is related to the problem with calling 32 FP...  in many cases 32 is VSR, instead12:43
segherit is still the same register12:43
segherjust how it is used differs12:44
segher32..95 are the 64 VSR registers12:44
segherit is very important (for compiler performance) that these are contiguous12:44
programmerjake[mmaybe it would help if we used my idea of having SimpleV based on 64x 128-bit registers instead of 128x 64-bit registers, that would map 1:1 to VSR regs12:48
seghereither way, before we can accept anything like this in GCC, you'll need to have the ABI defined12:57
segheryou can experiment with it outside of trunk of course12:58
lkclsegher: we're preserving full backwards compatibility with scalar v3.0B and very very specifically not going outside of function calls for now14:33
lkclso the ABI is defined as, "the ELF v1 ABI" or "the ELF v2 ABI"14:33
lkclor "the-current-ABI-that-is-used-for-OpenPOWER-v3.0B"14:33
lkclat some point we'll be in a position to define an ABI that crosses function-call boundaries, has its own triplet and/or is part of an "option" for a future revision of ELF V2...14:35
lkcl... but this is itself such a vast amount of work that we cannot delay proceeding just because of it14:35
lkcl*our funding from NLnet ends at the end of this year*14:36
lkclso we need to be a bit smart / careful about "what we take on" if you know what i mean14:55
segherlkcl: no15:49
segherfor the abi, you need to define the DWARF numbers for all your registers, for example15:49
segherabi is so much more than calling convention15:49
segherlkcl: i understand the difficult position you are in15:50
segherbut a project like GCC cannot afford to dedicate huge resources to something that does not even have a defined ABI yet15:51
segher(and it is not just GCC)15:51
lkclnngghhhh ok :)16:19
* lkcl deep breath, deep breath. i am in the centre of the lake. i am the lake. caaalm waters...16:19
lxolkcl, that's ok, I got those bits covered in my patch under development17:32
lxoindeed, it may very well be the case that the bug I mentioned I'm hunting down, that affects unwinding through signal frames, is failure to map some renumbered register back to the ABI-defined number17:34
lkcllxo: iinteresting18:05
* lkcl glad you're on the case18:06
programmerjake[mlxo: maybe try and build a function that uses all the registers, then look at the code with a debugger and see if the registers match up correctly18:15
programmerjake[mat the generated output code18:16
lxoprogrammerjake[m, I don't think it's any of the regular registers; those are remapped properly20:38
lkclmeeting 5mins21:55
lkclprogrammerjake[m, ^21:55
lkcllxo, ^21:55
mepyHow is going?22:39

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!