octavius | systemd-free distro supporting PII :) | 00:01 |
---|---|---|
octavius | http://download.tuxfamily.org/antix/docs-antiX-19/FAQ/index.html | 00:01 |
programmerjake | lkcl: https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=8bc92048f1cc65a28ecf0ab753be00206558ec6c | 00:10 |
lkcl | programmerjake, ah nice, good catch | 02:01 |
lkcl | octavius, that's a really good find, the anti-X distro. they're clearly "anti" systemd but are funny about it | 11:49 |
lkcl | whereas devuan is clearly "outrage outrage outrage outrage, anti anti anti anti" | 11:50 |
markos | fmvis should be done now, and just finished with fishmv as well, will commit in a sec | 12:00 |
markos | lkcl, please check | 12:01 |
markos | programmerjake, you too please, I think I understood now what you were saying, I kept forgetting that default fp representation on power is FP64 | 12:02 |
markos | lkcl, just saw the comment about minor_22.csv for fmvis | 12:05 |
markos | could you please explain again why OUT should be set to NONE? | 12:06 |
markos | now it's IN1=NONE, OUT=FRS and it seems to work, perhaps you meant that in the comment? | 12:07 |
lkcl | markos, willdo | 12:11 |
lkcl | in fmvis? because RS is not read, it's produced. | 12:12 |
lkcl | in fmvis, all the bits of RS not set to the immediate are set to zero | 12:12 |
lkcl | in fishmv, you have to *add* 16 bits of immediate into the *existing* value of RS. | 12:13 |
lkcl | markos, yes i botched up on minor_22.csv, realised i'd made a mistake and reverted it. | 12:13 |
lkcl | you got it right | 12:13 |
lkcl | - d0 = (imm >> 6) # MSBs 6-15 | 12:14 |
lkcl | + d0 = (imm >> 5) # MSBs 6-15 | 12:15 |
lkcl | i thought it might be something like that | 12:15 |
lkcl | hang on though... | 12:15 |
lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/fields.text;hb=HEAD#l426 | 12:15 |
lkcl | 426 d0,d1,d2 (16:25,11:15,31) | 12:15 |
lkcl | d0 is 25-16+1 = 10 bits long | 12:16 |
lkcl | d1 is 15-11+1 = 5 bits long | 12:16 |
lkcl | d2 is 31-31+1 = 1 bit long | 12:16 |
lkcl | 345 d2 = (imm & 1) # LSB (0) | 12:18 |
lkcl | 346 d1 = (imm >> 1) & 0b11111 # bits 1-5 | 12:18 |
lkcl | 347 d0 = (imm >> 5) # MSBs 6-15 | 12:18 |
lkcl | so that really doesn't look right / add up | 12:18 |
markos | indeed, the missing bit is the sign | 13:35 |
markos | just checked and it doesn't get copied | 13:35 |
markos | almost fixed, you are right, it needed >> 6 | 14:03 |
markos | there, that should really fix it | 14:18 |
markos | negative numbers work now too | 14:19 |
markos | lkcl, commit 04f20aa | 14:20 |
cesar | tplaten: I agree that there is a lot of duplication within gram and ls2. I guess, after we are satisfied that it really works, we can look into merging and refactoring. On LiteX, it's all centralized in litex-boards, maybe we can move common code into nmigen-boards. | 14:45 |
cesar | The CRG in ls2 seems more evolved and generic, but I suspect it's a work in progress. | 14:45 |
cesar | The simulation in ls2 seems to be more complete, including memory training. But it also includes a full simulated CPU, which is a bit overkill, I think, when we only want to test the controller, at first. For that, the headless simulation is better, it's just a Wishbone bridge wired to a Verilog testbench. | 14:51 |
cesar | (I am thinking into converting it into a cocotb testbench, maybe) | 14:54 |
lkcl | markos, hooray, that was a bitch of a job spotting the 27..30 instead of 26..30 | 14:56 |
lkcl | i even managed to get +/- inverted for about 10-15 minutes | 14:57 |
lkcl | so anyway, i'm happy with that, congratulations, EUR 2,000 is yours. | 14:59 |
ckie | hey, looking around the wiki but i can't tell what the state of the cpu part of the SoC is. i'm looking for a libre rpi equivalent | 16:04 |
octavius | hi ckie, libre-soc can be run on an fpga, however something like an rpi (with an asic) is little away | 16:06 |
octavius | currently the orange-crab and a few other fpga boards have been tested with the libre-soc core | 16:06 |
ckie | is it perhaps equivalent to the first rpi? | 16:06 |
octavius | No | 16:07 |
octavius | Actually hard to say | 16:07 |
octavius | I haven't ran it on an fpga myself | 16:07 |
ckie | what can it do then? | 16:09 |
octavius | Execute binaries (compatible with Microwatt PowerISA cpu), Tim at Raptor Computing was able to run a web server on it recently | 16:11 |
octavius | https://lists.libre-soc.org/pipermail/libre-soc-bugs/2022-July/007228.html | 16:12 |
octavius | Also I seem to remember there being a maze game running on it as well | 16:13 |
ckie | i guess i'll check in in a few years again then :p | 16:15 |
ckie | thanks! | 16:16 |
octavius | yw ckie :) | 16:16 |
lkcl | ckie, it should now run joel shenki's microwatt linux-5.7 now that tim helped triage running ZephyrOS | 18:32 |
lkcl | https://shenki.github.io/boot-linux-on-microwatt/ | 18:32 |
ghostmansd[m] | lkcl, are the recent insn additions complete, or should I wait for some changes and updates? | 19:42 |
ghostmansd[m] | I'm asking since if these are not ready yet, I can postpone adding them to binutils | 19:42 |
ghostmansd[m] | So this is rather a question "are these stabilized?" | 19:43 |
ghostmansd[m] | FWIW, I started working on disasm | 19:47 |
markos | programmerjake, is there a difference between DOUBLE2SINGLE() vs plain SINGLE() helper function? in the beginning I had the former but was getting wrong results, hence the change, but I guess the bug wasn't in the pseudocode, but the wrong indices in svp64.py's methods | 20:38 |
markos | thanks for the fix in any case, however I have to say I would appreciate it more if you would point me to the problem as that would give me more reason to investigate and learn from it | 20:40 |
markos | I don't mind others fixing my bugs though, far from it :) | 20:42 |
programmerjake | SINGLE() is the function used when the input is known to be a f32 in a f64, it doesn't round or anything, so it's a lot cheaper to implement in hardware. DOUBLE2SINGLE iirc does a round-to-nearest-ties-to-even (assuming default rounding mode) | 20:57 |
programmerjake | see fsts (f32 store) pseudocode for an example | 20:58 |
markos | I see, yes, it makes perfect sense, I'm sure I got bitten by the rounding in some numbers | 21:00 |
programmerjake | actually, if the input is already a f32 in f64, rounding will have no effect (except signalling -> quiet NaN conversion) | 21:01 |
programmerjake | see https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/helpers.py;hb=5f111b1fb9285c3605d0062bb41b50ac7fea550c#l178 | 21:03 |
markos | then it was too the effect of incorrect indices for d0 | 21:05 |
markos | anyway, I'm glad it got fixed | 21:05 |
programmerjake | yeah, probably | 21:05 |
programmerjake | oh, another difference: SINGLE is part of the PowerISA v3.1B spec, DOUBLE2SINGLE isn't | 21:14 |
octavius | meeting lkcl | 22:00 |
lkcl | programmerjake, yes they're all part of the Power ISA spec. i just didn't put SINGLE() in fphelpers.mdwn | 22:01 |
lkcl | def SINGLE(FRS): | 22:01 |
lkcl | """convert incoming FRS into 32-bit word. v3.0B p144 section 4.6.3 | 22:01 |
lkcl | """ | 22:01 |
markos | lkcl, updated ticket with numbers | 23:02 |
markos | might be off by a few | 23:03 |
markos | but really only a few | 23:03 |
programmerjake | i'm going to skip the librebmc meeting today, i have other stuff i need to do | 23:04 |
markos | lkcl, mind you that's intrinsics, not asm instructions, for Arm case it will make a difference as eg. ADD may have multiple intrinsic variants (vaddq_{s|u}{8|16|32|64}) but it's still considered one asm instruction with multiple forms | 23:06 |
markos | it's still a lot of instructions though, the only thing that saves arm development is that it's orthogonal and easy to remember/predict the name of an intrinsic | 23:07 |
markos | which isn't the case with Intel | 23:08 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!