| programmerjake | idk where you got the idea that I just now suggested SV's semantics should change...I didn't (though I have and still do suggest they change for other unrelated reasons...) | 05:27 |
|---|---|---|
| programmerjake | I was suggesting the simulator's design change... | 05:28 |
| ghostmansd | lkcl: nice patches, that's how I intended to do it today :-) | 07:51 |
| ghostmansd | Yep, basically the whole thing was "create a new instance to pass a new value". I actually thought of using copy.deepcopy, though, because I didn't want to touch selectable int internals. | 07:56 |
| ghostmansd | I'll try to take a look at addg6s test today. What'd be the right way to check qemu's behavior? Is there the right way to launch our qemu? Should I simply cross-compile some addg6s code and run the binary on qemu? What are the BKMs? | 08:01 |
| lkcl | programmerjake: ahh, right. the simulator respects SVP64 Program Order. | 11:12 |
| lkcl | anything that doesn't match that is a bug | 11:12 |
| lkcl | ghostmansd, python3 decoder/simulator/test_sim.py | 11:13 |
| lkcl | programmerjake, you said, "<programmerjake> afaik >>>SimpleV<<<< is the only ISA..." | 11:15 |
| lkcl | where retrospectively you probably meantto say "afaik ISACaller is the only simulator..." | 11:15 |
| lkcl | unfortunately - annoyingly - we need to be able to cope with the situation where the pseudocode requires direct access to GPR and FPR, making modifications through a direct call to set GPR and FPR contents | 11:17 |
| lkcl | i'm not going to make ISACaller do an entire copy of two 128-entry register files without a really *really* good reason | 11:18 |
| lkcl | ghostmansd: the one thing to watch out for is that element-width overrides are going to be a bit of a pig | 12:30 |
| lkcl | it will no longer be "64 bit add", it will be "if elwidth==8 do 8-bit add elif elwidth==16 do 16-bit add ..." | 12:31 |
| lkcl | accessing the regfile as if it was a c union of {uint8_t *b; uint16_t *h; uint32_t *i; uint64_t *l} | 12:32 |
| lkcl | https://libre-soc.org/openpower/sv/overview/#elwidths | 12:33 |
| lkcl | therefore, exactly at the point where the copy has been made, it will NOT be like that AT ALL | 12:34 |
| lkcl | it will instead be something like: | 12:34 |
| lkcl | reg_val = SelectableInt(self.gpr(regnum, srcstep, element_width)) | 12:34 |
| lkcl | where inside the GPR class, it will use the python equivalent of that typedef union | 12:35 |
| lkcl | regnum will *NOT* be calculated as "RA + srcstep" | 12:36 |
| lkcl | because that assumes that the element widths are fixed at 64-bit (8 bytes) | 12:36 |
| lkcl | where (normally, reasonably) you *assume* that the regfile is organised into 64-bit quantities | 12:37 |
| lkcl | elwidth overrides blow that out the water | 12:37 |
| lkcl | programmerjake: if there are design ideas that have not already been discussed and evaluated, now is the time to raise them. | 12:39 |
| lkcl | if they have already been discussed and evaluated, and you do not agree with the assessment that they not be implemented, please take the time to understand why the assessment was that they not be implemented | 12:41 |
| lkcl | particularly in light of the hard requirement that multi-issue execution not be impeded or compromised by any design decisions. | 12:42 |
| lkcl | some of the ideas that you, lxo, *and i* came up with all severely compromise multi-issue parallelism, creating dependency hazards either at decode or issue time. | 12:43 |
| lkcl | srcstep merged with SVP64 Branch-Conditional was the latest mistake that had to be backed out. | 12:44 |
| lkcl | this is how it is. | 12:44 |
| lkcl | you or i might *want* certain design features: reality is, they *have* to be practical to implement as multi-issue hardware | 12:45 |
| lkcl | key word: *practical* | 12:45 |
| programmerjake | well, the idea of having operations' endian match memory endian (which greatly simplifies the compiler and allows big-endian SV code to run at the same speed as little-endian SV code since it doesn't need extra endian-swapping instructions) is practical to implement (just 1 2-in mux on register read/write) and matches existing precedent of VMX, that was shot down... | 17:30 |
| lkcl | it's simple at the compiler, but absolutely horrendously complex at the register file and in the rest of the ISA. plus, i can't cope with it. | 17:40 |
| lkcl | i added a bit to REMAP which allows byte-swapping on a per-element basis | 17:40 |
| lkcl | that's as much as i can cope with. | 17:41 |
| lkcl | now, if someone (you) who advocates this idea *actually does the work* (rather than expecting me to implement it), creates a patch which adds it to both the HDL and the simulator then GREAT | 17:42 |
| lkcl | and edits and updates the spec, and writes the unit tests, and everything else that's required | 17:42 |
| lkcl | and demonstrates unequivocably that it's not going to cause massive headaches either in hardware or in actual understanding of the SVP64 concept, then it can be considered | 17:43 |
| lkcl | if that's sounding like it's a hell of a lot of work, that's because it is | 17:43 |
| lkcl | given that it's such an intrusive high-impact fundamental change, it needs to be properly thought through | 17:44 |
| programmerjake | so, in other words, your fine with the idea if you don't have to implement it? | 17:45 |
| lkcl | because i can't cope with it, mentally, given the logic-dyslexia and the complexity of everything else, basically, yes. | 17:45 |
| programmerjake | sounds good to me! I'd guess lxo will agree too... | 17:46 |
| lkcl | clarification: i'm not "totally fine with it" until it's actually *proven* and demonstrated not to be so massively intrusive and complex that it damages our chances of adoption and completion of the milestones set to date | 17:46 |
| lkcl | or results in unintended consequences well beyond "it's just a simple swap at the regfile" | 17:47 |
| programmerjake | ok | 17:48 |
| lkcl | before getting to implementation however, a comparative analysis will be needed vs the current option: existing LD/ST-byte-reversed (ldbr) when Vectorised, plus REMAP with byte-reverse enabled. | 17:52 |
| lkcl | what algorithms cannot be covered by that, where are they used, how often are they used, what is the cost | 17:53 |
| lkcl | etc. etc. etc. etc. | 17:53 |
| lkcl | all of which takes up a huge amount of time | 17:53 |
| programmerjake | ok...I'd expect the implementation to be simple enough that it might be easier to test it out by implementing it on a git branch or something... | 17:58 |
| programmerjake | then we can play with algorithms on the actual simulator | 17:59 |
| richardwilbur[m] | I think there is benefit to testing on the simulator that is probably directly proportional to the quality of the simulation. (It can be a pretty powerful test.) | 18:04 |
| programmerjake | definitely agree! | 18:10 |
| Madan_Kartheessa | I have sent you a message | 19:13 |
| *** Adithya46 <Adithya46!~Adithya@2405:201:e004:386e:9599:7651:a545:ee6d> has left #libre-soc | 19:16 | |
| *** Adithya51 <Adithya51!~Adithya@2405:201:e004:386e:9599:7651:a545:ee6d> has left #libre-soc | 19:17 | |
| programmerjake | https://xkcd.com/2503/ | 19:37 |
| ARJUN_NAG | Hello everyone | 20:01 |
| programmerjake | hi | 20:01 |
| richardwilbur[m] | Greetings Arjun. | 20:02 |
| ARJUN_NAG | Hello richard | 20:02 |
| ARJUN_NAG | Tq all | 20:02 |
| ARJUN_NAG | Thanks for the warm welcome | 20:02 |
| richardwilbur[m] | @Madan: Welcome to libre-soc IRC. | 20:03 |
| lkcl | nice to have you on board, Arjun and Madan_Kartheessa | 20:12 |
| lkcl | Arjun i recommend you use a username that does not have a space in it | 20:13 |
| lkcl | use an underscore instead, arjun_nag | 20:13 |
| programmerjake | lkcl, the username has an underscore | 20:13 |
| lkcl | doh, that'll be hexchat removing them, sigh | 20:13 |
| programmerjake | at least on my end | 20:14 |
| lkcl | https://github.com/hexchat/hexchat/issues/2449 | 20:14 |
| lkcl | ahh | 20:14 |
| lkcl | that's annoying: it's an issue with libpango | 20:15 |
| ghostmansd-pc | test_sim.py doesn't seem to work on my side; `TypeError: __init__() got an unexpected keyword argument 'gdb_path'` | 20:15 |
| ghostmansd-pc | it looks like the arguments are wrong, the only argument is command, acting as list of strings | 20:16 |
| lkcl | ghostmansd-pc: 1 sec | 20:16 |
| lkcl | i haven't run test_sim.py for a few months | 20:17 |
| ghostmansd-pc | tried using `['powerpc64-linux-gnu-gdb'] + pygdbmi.DEFAULT_GDB_LAUNCH_COMMAND[1:]` instead | 20:17 |
| ghostmansd-pc | got qemu-system-ppc64le: -machine powernv9: unsupported machine type | 20:17 |
| richardwilbur[m] | I also see the underscore in @ARJUN_NAG in Element. | 20:18 |
| lkcl | ghostmansd-pc: ok test_sim.py worked fine here | 20:18 |
| lkcl | let me check the code | 20:18 |
| ghostmansd-pc | and, in the end, 48 skips and 7 failures after that: `pygdbmi.constants.GdbTimeoutError: Did not get response from gdb after 1 seconds` | 20:18 |
| ghostmansd-pc | can it happen that we have different pygdbmi? | 20:19 |
| programmerjake | for the unsupported machine type, that sounds like you have an old version of qemu... | 20:19 |
| lkcl | honestly it's not very stable: do "ps aux | grep qemu" and if it's still running, you have to *manually* kill it | 20:19 |
| lkcl | ii qemu-system-ppc 1:4.2-3 amd64 QEMU full system emulation binaries (ppc) | 20:19 |
| lkcl | r$ qemu-system-ppc64 --version | 20:20 |
| lkcl | QEMU emulator version 4.2.0 (Debian 1:4.2-3) | 20:20 |
| ghostmansd-pc | no running qemu | 20:21 |
| ghostmansd-pc | let me re-check for version | 20:21 |
| ghostmansd-pc | yikes | 20:21 |
| ghostmansd-pc | extremely old... | 20:21 |
| ghostmansd-pc | QEMU emulator version 3.1.0 (Debian 1:3.1+dfsg-8+deb10u8) | 20:21 |
| ghostmansd-pc | hm, this is strange, I recall I followed the routine at HDL workflow | 20:22 |
| ghostmansd-pc | let me re-check the script I used | 20:22 |
| ghostmansd-pc | it's simply `qemu-system-ppc` | 20:23 |
| lkcl | warl, they'rs yur prabbhlurm... :) | 20:23 |
| ghostmansd-pc | :-D | 20:23 |
| ghostmansd-pc | perhaps compiling from sources? | 20:23 |
| lkcl | can't find the appropriate mythbusters youtube video but hey | 20:23 |
| ghostmansd-pc | would that work? not really HDL-ish, but hey | 20:24 |
| lkcl | let me check what's in debian/10 (which version of qemu) | 20:24 |
| ghostmansd-pc | HDL-workflowish, so to speak | 20:24 |
| programmerjake | apparently powernv9 was added in qemu 4.2: https://wiki.qemu.org/ChangeLog/4.2 | 20:24 |
| lkcl | https://packages.debian.org/search?keywords=qemu-system-ppc | 20:24 |
| lkcl | drat. | 20:24 |
| lkcl | i installed qemu from debian/testing about 18 months ago | 20:25 |
| lkcl | programmerjake: yeah that looks about right, 4.2 would have been in debian/testing back then | 20:25 |
| ghostmansd-pc | $ cat /etc/*release* | head -n1 | 20:25 |
| ghostmansd-pc | PRETTY_NAME="Debian GNU/Linux 10 (buster)" | 20:25 |
| lkcl | they've since moved on to... 5.2 https://packages.debian.org/bullseye/qemu-system-ppc | 20:26 |
| lkcl | ahh there's a debian/10 backport | 20:26 |
| lkcl | urrr.. | 20:26 |
| lkcl | ghostmansd-pc: try the debian/10 backport version | 20:26 |
| ghostmansd-pc | https://packages.debian.org/buster-backports/qemu-system-ppc? | 20:27 |
| lkcl | yes | 20:27 |
| lkcl | you know how to add backports to debian sources.list? | 20:27 |
| richardwilbur[m] | Does that need an edit to sources.list? | 20:27 |
| lkcl | (add it to /etc/apt/sources.list.d/buster_backports) | 20:27 |
| ghostmansd-pc | that was lot ago | 20:28 |
| lkcl | richardwilbur[m], an entry in sources.list.d is better / cleaner | 20:28 |
| ghostmansd-pc | ok, sounds fair :-) | 20:28 |
| richardwilbur[m] | Sorry, old debian-fu. | 20:28 |
| ghostmansd-pc | deb http://deb.debian.org/debian buster-backports main | 20:29 |
| ghostmansd-pc | poor man's jump into the future | 20:29 |
| lkcl | ngggh there's something else... have to do "apt-get install qemu-system-ppc/{insertversion}" | 20:30 |
| ghostmansd-pc | yep | 20:30 |
| ghostmansd-pc | apt-get install qemu-system-ppc/buster-backports | 20:30 |
| lkcl | otherwise you have to piss about with /etc/apt/preferences | 20:30 |
| lkcl | ahhh awesome | 20:30 |
| ghostmansd-pc | locked and loaded! | 20:31 |
| ghostmansd-pc | $ qemu-system-ppc64 --version | 20:31 |
| ghostmansd-pc | QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-9~bpo10+1) | 20:31 |
| ghostmansd-pc | Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers | 20:31 |
| ghostmansd-pc | awesome, thanks, folks! | 20:31 |
| richardwilbur[m] | Probably better to use backports because you can pick and choose what you want to update rather than getting dragged kicking and screaming into new versions of pretty much everything. | 20:32 |
| lkcl | has to have a .list on the file extension | 20:32 |
| ghostmansd-pc | I wonder if I have pygdbmi OK | 20:33 |
| lkcl | ok err it's removing openbios-ppc but hey | 20:33 |
| ghostmansd-pc | File "/usr/local/lib/python3.7/dist-packages/pygdbmi-0.10.0.1-py3.7.egg/pygdbmi/IoManager.py", line 98, in get_gdb_response | 20:34 |
| ghostmansd-pc | "Did not get response from gdb after %s seconds" % timeout_sec | 20:34 |
| ghostmansd-pc | pygdbmi.constants.GdbTimeoutError: Did not get response from gdb after 1 seconds | 20:34 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=install-hdl-apt-reqs;hb=HEAD | 20:34 |
| lkcl | ghostmansd-pc, you have powerpc64-linux-gnu-gdb installed? | 20:34 |
| lkcl | (that one has to be from source) | 20:34 |
| ghostmansd-pc | this one is compiled iirc | 20:35 |
| ghostmansd-pc | yep, $ powerpc64-linux-gnu-gdb --version | head -n1 | 20:35 |
| ghostmansd-pc | GNU gdb (GDB) 8.3 | 20:35 |
| lkcl | $ powerpc64-linux-gnu-gdb --version | 20:35 |
| lkcl | GNU gdb (GDB) 9.1 | 20:35 |
| lkcl | no idea if that makes any difference | 20:35 |
| ghostmansd-pc | but let me re-install hdl-apt-reqs with backports | 20:35 |
| lkcl | ok | 20:35 |
| ghostmansd-pc | (I guess it's there since now, right?) | 20:35 |
| ghostmansd-pc | in URL to git you posted | 20:35 |
| lkcl | then try just running openpower/simulator/qemu.py | 20:35 |
| lkcl | but do "make" first in the... errr.... which directory... | 20:36 |
| ghostmansd-pc | openpower-isa | 20:36 |
| lkcl | simulator/qemu_test directory | 20:36 |
| lkcl | openpower-isa/src/openpower/simulator/qemu.py | 20:36 |
| ghostmansd-pc | hm | 20:36 |
| ghostmansd-pc | OK, will be back soon | 20:36 |
| lkcl | and openpower-isa/src/openpower/qemu_test/Makefile | 20:36 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/simulator/qemu_test/README.md;hb=HEAD | 20:37 |
| lkcl | eliminate things from the chain to triage the problem | 20:38 |
| ghostmansd-pc | ok, install-hdl-apt-reqs doesn't do anything, I'm already brand new as ever possible | 20:39 |
| lkcl | excellent | 20:39 |
| lkcl | that README will allow you to run qemu-system-ppc "directly" (not involving pygdbmi) | 20:40 |
| lkcl | however it's a foreground process that eats console | 20:40 |
| lkcl | so you need to run it in a separate xterm | 20:40 |
| ghostmansd-pc | launch.sh hangs... | 20:41 |
| ghostmansd-pc | so is `qemu-system-ppc64 -machine powernv9 -nographic -s -S -kernel kernel.bin` | 20:41 |
| lkcl | yes, that's the correct thing | 20:42 |
| lkcl | then in a *second* xterm you run the other command | 20:42 |
| lkcl | (see the README) | 20:42 |
| ghostmansd-pc | ah, OK | 20:43 |
| lkcl | i did say: it eats console input. this is expected behaviour | 20:43 |
| ghostmansd-pc | the readme doesn't mention that these are different consoles | 20:43 |
| ghostmansd-pc | it shows the commands as sequential | 20:43 |
| ghostmansd-pc | OK, I'm at 0x10 | 20:44 |
| ghostmansd-pc | after ENTER the breakpoint is added, and I reach it | 20:45 |
| lkcl | excellent. | 20:45 |
| ghostmansd-pc | I'm at kernel entry point | 20:45 |
| ghostmansd-pc | [ 7.204320677,5] INIT: Starting kernel at 0x20000000, fdt at 0x306c8ef8 23888 bytes | 20:45 |
| lkcl | ok so both qemu-system-ppc and powerpc64-linux-gnu-gdb are "functional" | 20:45 |
| ghostmansd-pc | brk is also at x20000000 | 20:45 |
| lkcl | per se | 20:45 |
| lkcl | all good. | 20:45 |
| ghostmansd-pc | ok, `kill` in gdb? | 20:45 |
| lkcl | so that's not the source of the problem | 20:45 |
| lkcl | probably :) | 20:46 |
| lkcl | i just killed it manually (killall qemu-system-ppc) | 20:46 |
| ghostmansd-pc | qemu-system-ppc64le: cannot set up guest memory 'pnv.ram': Cannot allocate memory | 20:47 |
| lkcl | next thing: do the programs... ahhh | 20:47 |
| lkcl | that's weird | 20:47 |
| ghostmansd-pc | I think this might have to do with it | 20:47 |
| ghostmansd-pc | incantation I use is `python3 src/openpower/simulator/test_sim.py` | 20:48 |
| lkcl | how much RAM do you have on your laptop? | 20:48 |
| lkcl | '-s', '-S', '-m', 'size=4096'] | 20:48 |
| lkcl | launch_args_le = ['qemu-system-ppc64le', | 20:48 |
| lkcl | that's asking for 4 GIGABYTES which is quite a lot | 20:48 |
| lkcl | if physical RAM is the problem you might be able to bring that down to a much more sane size=1024 or even size=512 | 20:49 |
| ghostmansd-pc | lol, much less | 20:49 |
| ghostmansd-pc | let me first allocate more RAM to VM | 20:49 |
| lkcl | what the heck we're doing asking for 4 gigabytes of RAM to execute programs of size 12 bytes is anybody's guess | 20:49 |
| programmerjake | ^ probably part of why it's slow | 20:50 |
| ghostmansd-pc | lmao, 640K ought to be enough for anybody | 20:50 |
| programmerjake | well, if we're just testing a few instructions, try setting it to 1MB | 20:50 |
| lkcl | pygdbmi is unfortunately rather badly designed | 20:51 |
| ghostmansd-pc | `qemu-system-ppc64le: warning: skiboot may not work with < 1GB of RAM` | 20:51 |
| ghostmansd-pc | that's just a warning | 20:51 |
| lkcl | it was never intended for mass-management to the extent we're using it | 20:52 |
| lkcl | it has a timeout of 1 second on the socket | 20:52 |
| ghostmansd-pc | used `size=32`, perhaps way too little | 20:52 |
| ghostmansd-pc | sigh | 20:52 |
| ghostmansd-pc | still `pygdbmi.constants.GdbTimeoutError: Did not get response from gdb after 1 seconds` | 20:52 |
| lkcl | hmm | 20:53 |
| lkcl | ohhh hang on | 20:53 |
| lkcl | you're running qemu *inside* a VM, right? | 20:53 |
| lkcl | an emulator inside an emulator, right? | 20:53 |
| ghostmansd-pc | yes, but this should work, isn't it? | 20:53 |
| lkcl | yyeahhh but only if you enable the right options in the top-level emulator | 20:53 |
| ghostmansd-pc | I mean, nesting is usually supported | 20:53 |
| programmerjake | or is the VM using native virtualization? | 20:53 |
| lkcl | tcktcktck.... | 20:54 |
| ghostmansd-pc | lol, qemu is still running, even though the test's completed with fails | 20:54 |
| * lkcl thinks | 20:54 | |
| ghostmansd-pc | and it eats my CPU | 20:54 |
| lkcl | ah that's actually "bad" | 20:54 |
| lkcl | kill it | 20:54 |
| ghostmansd-pc | yep | 20:54 |
| ghostmansd-pc | at least the laptop is warm, lol | 20:54 |
| lkcl | ha, it could just be that by running qemu-within-qemu it's just far too slow | 20:54 |
| lkcl | :) | 20:54 |
| lkcl | and the 1 second timeout is simply too short | 20:55 |
| programmerjake | do note that powernv9 means Power9 without virtualization | 20:55 |
| lkcl | errrmmmermermerm... https://github.com/cs01/pygdbmi/blob/master/pygdbmi/gdbcontroller.py | 20:56 |
| lkcl | https://github.com/cs01/pygdbmi/blob/master/pygdbmi/constants.py | 20:56 |
| lkcl | get_gdb_response is where the timeout is set to 1s... | 20:57 |
| ghostmansd-pc | constants.py:3:DEFAULT_GDB_TIMEOUT_SEC = 1 | 20:58 |
| lkcl | ahh and also to the "write" function | 20:58 |
| lkcl | ok | 20:58 |
| lkcl | yes. | 20:58 |
| lkcl | so... | 20:58 |
| ghostmansd-pc | do you think I should increase it? | 20:58 |
| lkcl | self.gdb.write("data").... | 20:58 |
| lkcl | yes. | 20:58 |
| lkcl | you can monkey-patch it | 20:58 |
| lkcl | at the *very first* line | 20:59 |
| lkcl | from pygdbmi import constants | 20:59 |
| lkcl | then | 20:59 |
| ghostmansd-pc | you mean overriding it? | 20:59 |
| lkcl | line 2: constants.DEFAULT_GDB_TIMEOUT_SEC = 5 | 20:59 |
| ghostmansd-pc | pygdbmi.DEFAULT_GDB_TIMEOUT_SEC = 666? | 20:59 |
| lkcl | yes. | 20:59 |
| ghostmansd-pc | yep | 20:59 |
| ghostmansd-pc | will do | 20:59 |
| lkcl | monkey-patching is such a dreadful hack... | 21:00 |
| lkcl | only really good reason i've seen it used is stackless | 21:00 |
| lkcl | they (hilariously) monkey-patch all python standard socket routines (!) | 21:01 |
| ghostmansd-pc | what for? they wanted some stuff before/after actual code? | 21:01 |
| ghostmansd-pc | no luck with changed constants, but at least laptop got warmer again :-) | 21:02 |
| ghostmansd-pc | killed the qemu beast again | 21:03 |
| lkcl | :) | 21:03 |
| programmerjake | is the VM running out of ram and swapping like crazy! | 21:04 |
| programmerjake | ? | 21:04 |
| lkcl | if this is getting in the way, we can do it differently: hand-crafted values of addg6s. | 21:04 |
| lkcl | calculate what they're supposed to be, and add them to the test_caller_bcd.py | 21:05 |
| lkcl | but also add a qemu test as well, which one of us can run | 21:05 |
| ghostmansd-pc | programmerjake: 100% cpu at top | 21:05 |
| ghostmansd-pc | fwiw, maybe I could edit kernel.bin? | 21:05 |
| * lkcl need to get up and walk about | 21:06 | |
| lkcl | kernel.bin should be a few bytes. it won't be the problem, itself | 21:06 |
| ghostmansd-pc | ah, nice, there's even test.s which is used as source for kernel | 21:07 |
| ghostmansd-pc | lkcl: nope, I mean, I could insert an instruction there and inspect the registers | 21:07 |
| ghostmansd-pc | (if $(AS) knows it) | 21:08 |
| ghostmansd-pc | (even if not, I could perhaps insert the instruction via objcopy or by other means) | 21:08 |
| lkcl | ghostmansd-pc, yes | 21:09 |
| ghostmansd-pc | addg6s 1,1,1 | 21:09 |
| ghostmansd-pc | I did it for lulz, and it compiles | 21:09 |
| lkcl | w00t | 21:10 |
| ghostmansd-pc | we're not looking for an easy ways, right? ;-) | 21:10 |
| ghostmansd-pc | *way | 21:10 |
| lkcl | omg we've regressed to l33t speek | 21:10 |
| ghostmansd-pc | that's the direct consequence of qemu eating the whole CPU | 21:11 |
| lkcl | just the easiest repeatable way to confirm that the pseudocode's actually correct | 21:11 |
| ghostmansd-pc | ok, I think I'll simply edit test.s, compile it and run with qemu, attaching with gdb | 21:11 |
| ghostmansd-pc | maybe even some custom gdb script, don't know for sure yet | 21:12 |
| lkcl | it's ISACaller that needs a repeatable test | 21:13 |
| lkcl | although... ohh i get it | 21:13 |
| lkcl | you can hand-edit test.s | 21:13 |
| lkcl | to generate arbitrary values | 21:13 |
| lkcl | see what those look like and insert them into test_caller_bcd.py | 21:13 |
| lkcl | blech :) | 21:13 |
| ghostmansd | Yep, that's what I wanna do :-) | 21:21 |
| ghostmansd | ugly yet effective | 21:21 |
| ghostmansd | I even think... Hell, yeah, I can generate the whole listing via Python | 21:21 |
| ghostmansd | (not all values though) | 21:22 |
| ghostmansd | I'll have to re-check the instruction itself | 21:22 |
| ghostmansd | Perhaps at 20th read I'll finally understand why they need it, lol | 21:22 |
| ghostmansd | What I like in programming is that sometimes it naturally _forces_ you to be creative | 21:23 |
| programmerjake | lkcl, ghostmansd afaict qemu doesn't support any of cbcdtd, cdtbcd, or addg6s, I couldn't find them via grepping through qemu master or by going through all occurrences of "bcd" | 21:27 |
| programmerjake | https://lists.nongnu.org/archive/cgi-bin/namazu.cgi?query=cbcdtd&submit=Search%21&idxname=qemu-ppc&max=20&result=normal&sort=score | 21:29 |
| programmerjake | not on mailing list either | 21:30 |
| ghostmansd-pc | hm | 21:30 |
| ghostmansd-pc | not sure of qemu, as supports it, though | 21:30 |
| ghostmansd-pc | let me check it | 21:30 |
| ghostmansd-pc | perhaps it can be compiled but not run | 21:31 |
| ghostmansd-pc | gdb knows it... | 21:31 |
| ghostmansd-pc | stepi does something strange, though; after entering `stepi` at address 0x20000000 I somehow end up at 0xe40 | 21:33 |
| programmerjake | sounds like an illegal instruction trap | 21:35 |
| ghostmansd-pc | https://lists.gnu.org/archive/html/qemu-devel/2016-11/msg01003.html | 21:36 |
| ghostmansd-pc | yes, looks like an illegal instruction, `add` instruction works OK with `stepi` | 21:40 |
| ghostmansd-pc | https://gitlab.com/search?search=addg6s&group_id=3038080&project_id=11167699&scope=&search_code=true&snippets=false&repository_ref=master&nav_source=navbar | 21:42 |
| ghostmansd-pc | no luck | 21:42 |
| ghostmansd-pc | looks like we'll be the pioneers | 21:43 |
| richardwilbur[m] | Interesting how the qemu-devel message from Nov 2016 mentions addg6s and a whole slew of BCD instructions. Did they just not implement them in qemu? | 21:48 |
| ghostmansd-pc | if I got correctly, they're talking of risu | 21:49 |
| ghostmansd-pc | I've checked https://git.linaro.org/people/pmaydell/risu.git | 21:51 |
| ghostmansd-pc | that's all they have... | 21:51 |
| ghostmansd-pc | $ grep -nri addg6s . | 21:51 |
| ghostmansd-pc | ./ppc64.risu:56:# format:XO book:I page:110 v:2.06 addg6s Add & Generate Sixes | 21:51 |
| ghostmansd-pc | ./ppc64.risu:57:ADDG6S PPC64LE 111111 rt:5 ra:5 rb:5 00010010100 \ | 21:51 |
| ghostmansd-pc | not much, it looks like they simply generate the instruction, which kinda expected, since risu means "random instruction sequence generator" | 21:52 |
| ghostmansd-pc | OK, I think I'll take another look at addg6s tomorrow | 21:53 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!