IRC channel logs

<oriansj>having to do 2 instructions to load 1 value, never seemed like a good idea to me; you might as well do a jump 4 (or 8) and loadr from the instruction cache and it'll be just as fast

<oriansj>and save yourself the encoding bits in the process

<muurkha>yeah, you need separate argument and return stacks to have a stack language with subroutines. so every stack language has separate argument and return stacks: Forth, PostScript, HP FOCAL

<muurkha>RISC-V is in theory relatively agnostic about your control flow but there are a couple of registers they recommend using as link registers in particular ways to help out the branch predictor

<muurkha>using a link register rather than a hardware stack for calls sort of implicitly gives you more flexibility to separate the return stack

<muurkha>it would indeed be nice to have postdecrement and preincrement addressing modes

<muurkha>I think RISC-V got more uptake than the OpenRISC 1000 because its designers were more influential

<muurkha>but maybe it's also actually better, especially in the microcontroller space where RISC-V has taken off so far

<pabs3>didn't RISC-V go 64-bit earlier too?

<muurkha>probably, but that's because people were using it, I think

<muurkha>I was really excited the first time I saw Linux boot on an OpenRISC 1000

<muurkha>probably about 02004? at the Freedom Technology Center

<muurkha>the future looked a lot brighter then

<pabs3>ISTR there was also some blocker to getting the code into gcc mainline, copyright assignment perhaps

<muurkha>for OR1000?

<muurkha>I assumed it was that the GCC folks were reluctant to accept the maintenance burden of a hobby machine that nobody was using

<luke-jr>that'd be a better reason than copyright assignment politics

<pabs3>OpenRISC is in all Allwinner ARM SoCs https://linux-sunxi.org/AR100/

<pabs3>so I'm not sure it counts as a hobby machine

<pabs3>er https://linux-sunxi.org/AR100

<pabs3>copyright assignment was blocking the GCC RPi VC4 support for some time, now just because they can't be bothered https://github.com/itszor/vc4-toolchain/issues/7

<pabs3>some potentially useful links re or1k & gcc upstream: https://paste.debian.net/hidden/b760f3ac/

<sam_>you can use signed-off-by for gcc nowadays right

<muurkha>pabs3: it did at the time I saw it

<muurkha>there are a lot of questionable design choices in OpenRISC visible in that page

<muurkha>a delay slot, a flags register, conditional move, etc.

<muurkha>apparently GCC 9 does support it

<muurkha>the copyright assignment stuff is mentioned there too

<muurkha>I'm assuming olofk mentioned there is the author of the SeRV implementation of RISC-V

<muurkha> http://archive.tcltk.co.kr/files/misc/or32/crosschain/sites/www.meansoffreedom.com/index.html is now 404 :(

<muurkha> https://lkml.org/lkml/2018/2/26/45 also talks about the copyright assignment thing

<muurkha>there's a great-looking presentation comparing the architectures at https://iis-people.ee.ethz.ch/~gmichi/asocd/lecturenotes/Lecture6.pdf including a lovely plot of my very favorite figure of merit: picojoules per instruction

<pabs3>there is https://web.archive.org/web/20150801222007/http://meansoffreedom.com/

<muurkha>for now

<muurkha> https://stackoverflow.com/a/54725021 explains why branch delay slots are considered a mistake

<muurkha>oh, and interestingly, shap also responded to the question with notes about HAL sped up their SPARC: https://stackoverflow.com/a/60920481

<muurkha>I didn't know he worked at HaL

<muurkha> https://riscv.org/blog/2014/10/why-not-build-on-openrisc/ is Asanovic explaining why RISC-V didn't just use OpenRISC

<[exa]>oriansj: yeah the separate return stack is a complete magic if used properly

<[exa]>there's even some effort to have continuation stacks, that's just lovely

<muurkha>what do you mean?

<muurkha>normally a continuation is more or less the contents of the operand and return stacks

<[exa]>muurkha: continuations tend to change size unpredictably and aren't very handy for being copied around...so an extra stack for these helps

<muurkha>[exa]: but you might not access them in a stack-like fashion?

<muurkha>I'm not understanding the concept

<oriansj>muurkha: picojoules per instruction definitely sounds more implementation specific than anything based in the architecture. (See RISC-V in ECL vs VAX in 5nm CMOS)

<rickmasters>oriansj: wondering if you have seen/have any thoughts on https://github.com/oriansj/mescc-tools/issues/44 ?

<rickmasters>oriansj: I am using a locally patched hex2 as a workaround for builder-hex0 development

<oriansj>rickmasters: thank you for identifying that problem; I think the solution is simpler. treat $labels as unsigned [as they are absolute addresses] and @labels as signed [as they are displacements]

<oriansj>and I probably should fix that M1 bug as well

<rickmasters>oriansj: I think that's what the attached PR does; it alters range_check to allow up to 65535 for $labels

<oriansj>merged

<rickmasters>oriansj: thank you

<rickmasters>oriansj: looks like there are other copies of hex2 in stage0-posix, on savannah, checksums to be updated, a bunch of work. sorry :)

<oriansj>and I'll do a matching change on M1 to fix that bug you reported

<oriansj>no worries

<oriansj>roconnor: I just noticed your pull request. thank you.

<oriansj>merged

<oriansj>hmmm making M1 support unsigned; might be a breaking change if one assumes @40000 works but $40000 would be the unsigned version

<oriansj>anyone have an issue with that assuming it is part of the next mescc-tools release?

<oriansj>(with $42 and &42 being unsigned 16 and unsigned 32bits respectively)

IRC channel logs

2023-06-05.log