| ghostmansd-pc | 4) we also quite often use another pattern -- XLEN*2 and XLEN*2-1 respectively (making up a 128-bit variable and filling it) | 06:46 |
|---|---|---|
| ghostmansd | It seems some of my messages were dropped, re-sending | 07:53 |
| ghostmansd-pc | > so far most of pseudocode I've seen needs three types of adjustments wrt XLEN | 07:54 |
| ghostmansd-pc | > 1) get the first half of the register/variable (0:31) | 07:54 |
| ghostmansd-pc | > 2) get the second half of the register/variable (32:63) | 07:54 |
| ghostmansd-pc | > 3) get the sign (usually EXTS64) | 07:54 |
| ghostmansd-pc | > I assume there's a way to get these from a selectable int; what do you think if we establish three helpers? | 07:54 |
| ghostmansd-pc | > yes, we have .value/.bits in selectable int | 07:54 |
| ghostmansd-pc | > Hm. We have EXTZ function in pseudo-code, but there's none in helpers or isa/functions. Is there some dark magic behind it, or it's not tested? | 07:54 |
| ghostmansd-pc | > 4) we also quite often use another pattern -- XLEN*2 and XLEN*2-1 respectively (making up a 128-bit variable and filling it) | 07:55 |
| programmerjake | adding helpers sounds good | 07:56 |
| programmerjake | I'll let lkcl comment since I'm going to sleep | 07:59 |
| ghostmansd-pc | I'm also not sure about division, cf. divw et al. These are explicitly mentioned as ones that operate on specific width. The dividend checks are explicit (0x8000_0000, 0x8000_0000_0000_0000 and so on). | 10:16 |
| ghostmansd-pc | This doesn't seem to apply to an unsigned divisions, though. | 10:20 |
| ghostmansd-pc | programmerjake: I assume it's not OK to have MemoryError in test_pipe_caller_long.py, like one I have? https://pastebin.com/GU0Mgkiq | 10:35 |
| lkcl | we eeed to be extra careful about how much in the way of helpers is added | 11:01 |
| lkcl | the "second phase" of the elwidth changes is to *override* the behaviour of every (existing) helper function | 11:02 |
| lkcl | by first adding every single helper function to a *class* - rather than as globals | 11:02 |
| lkcl | and thus allowing the helper function(s) - all of them - to also gain access to XLEN | 11:03 |
| lkcl | the pseudocode compiler would then be responsible for identifying that a helper was used and output "self.{INSERTHELPERNAME}" instead of just {INSERTHELPERNAME} as is done right now | 11:03 |
| lkcl | every new helper added will be required to have *full documentation* with a corresponding Request for Change to be submitted to the OpenPOWER ISA Working Group | 11:05 |
| lkcl | it should not be done blithely, lightly, or arbitrarily "because we feel like it" | 11:06 |
| lkcl | occurrences of "0x8000_0000_0000_0000" (etc) i believe can be replaced with "0b1 | [0b0]*(XLEN-1)" | 11:07 |
| lkcl | and the 0x7fff_ffff_ffff with the inverse | 11:08 |
| lkcl | the general practice of the spec has always been to spell things out explicitly, except where it's clearly going to be a royal nuisance. EXTS, EXTZ etc. | 11:15 |
| lkcl | there is no hard reason why the EXTZ (etc.) helper functions aren't used in the isafunctions (pyfnwriter). it will simply be down to the fact that nobody who has contributed to the spec has made use of any of them... yet | 11:17 |
| lkcl | my main point about the aversion to adding new helpers is that we need to think less like programmers and more like specification writers | 11:18 |
| lkcl | in other words: think it through from two perspectives | 11:46 |
| lkcl | 1) how much effort do we have to put into formally submitting Requests for Change to the spec (through the ISA WG, who have to vote on all and any proposed updates) | 11:47 |
| lkcl | 2) when someone is smacked between the eyes like a 2x4 with a whopping 1,300 page document, what are the odds they'll read all of it? | 11:47 |
| lkcl | pretty much zero | 11:47 |
| lkcl | they'll jump in, read a page, jump out. | 11:47 |
| lkcl | the spec is *already* obtuse as hell | 11:48 |
| lkcl | if there's references to things that have to be looked up on another page, that makes it even more hostile to use (and thus risks them making mistakes) | 11:48 |
| lkcl | therefore | 11:48 |
| lkcl | what i am saying is | 11:48 |
| lkcl | despite it being "inconvenient" (and exactly the kind of thing that drives a programmer nuts), *less* helpers and more *explicit expansion* is actually better | 11:49 |
| lkcl | if it's explicitly spelled out, everything is right there, on the (one) page right in front of the person who's trying desperately to get to grips with an overwhelmingly-large document | 11:50 |
| ghostmansd-pc | ok, fair enough | 13:41 |
| ghostmansd-pc | I'm not adding the helpers now, anyway :-) | 13:41 |
| ghostmansd-pc | Has anyone met the error I have in test_pipe_caller_long.py? https://pastebin.com/GU0Mgkiq | 13:42 |
| ghostmansd-pc | I'd like to test what I changed so far, but these are mostly mul/mod/unsigned-div instructions, and these are checked by test_pipe_caller_long.py. | 13:45 |
| ghostmansd-pc | programmerjake, please, correct me if I'm wrong. :-) | 13:46 |
| ghostmansd-pc | Hm. What's the sign position in Power? | 14:01 |
| ghostmansd-pc | Isn't it the last bit? | 14:01 |
| ghostmansd-pc | I'm looking at extsb. I'd have expected 63 instead of 56 as sign bit. | 14:02 |
| ghostmansd-pc | For things like cmpb, 7 in the loop must be changed to (XLEN/8)-1 (there are other loops which depend on XLEN). I've taught the parser to support expressions instead of constants, since it seemed to be the simplest way. That said, the simplest is not necessarily the best. | 15:43 |
| ghostmansd-pc | Basically it boils down to calling a custom RANGE instead of range. The RANGE (a name is really appreciated) checks start/end mismatch (previously done in parser.py), and returns a range. | 15:50 |
| ghostmansd-pc | Hm. Here's what we have in specs: | 15:55 |
| ghostmansd-pc | s ⊕ (RS)i%8+7 | 15:55 |
| ghostmansd-pc | and that's what we have in code: | 15:56 |
| ghostmansd-pc | s <- s ^ (RS)[i*8+7] | 15:56 |
| ghostmansd-pc | prty instruction | 15:56 |
| ghostmansd-pc | sorry, prtyd | 16:02 |
| programmerjake | ghostmansd-pc for the MemoryError, are you using a 32-bit python, since on 64-bit linux that will basically never happen, it'll get killed first. if you made a powerpc vm, it should be a powerpc64le vm | 16:24 |
| programmerjake | assuming you have 32-bit linux, it got killed because it is using more than 2-4GB of memory for error messages or other junk... | 16:27 |
| programmerjake | either that or some native extension has a memory leak | 16:28 |
| programmerjake | you can try running test_pipe_caller_long.py with the -f flag, it'll make it stop at the first error | 16:34 |
| ghostmansd | I'm using a 64-bit x86 Debian inside VM | 16:43 |
| programmerjake | the sign position is the msb of whatever size thing your dealing with, so a 64-bit signed integer in a 64-bit register has the sign bit at bit 0, a 32-bit in a 64-bit has the sign at bit 32, an 8-bit in a 64-bit has the sign at bit 56, etc. | 16:43 |
| programmerjake | that should work then... | 16:43 |
| programmerjake | hmm.... | 16:43 |
| ghostmansd | Perhaps I gave too little RAM: 2048 MiB | 16:44 |
| programmerjake | I'll try it myself later today | 16:44 |
| ghostmansd | about the sign: a series of deep sighs | 16:44 |
| programmerjake | yes...msb0 is a pain | 16:44 |
| programmerjake | assuming you'll want to compile llvm or gcc or run coriolis2 at some point, you'll definitely want more than 2GB, i'd give it as much as you can without leaving your host system memory starved | 16:46 |
| programmerjake | it might be better to install linux along-side your other os rather than running in a vm | 16:47 |
| programmerjake | so, if you have 8GB ram, try giving the VM 6GB or so | 16:48 |
| lkcl | where there are for-loops 0 to 7 we have to think, on a case-by-case basis, is it: | 17:51 |
| lkcl | (a) more sensible to do 8/4/2/1 things of always 8-bit wide | 17:51 |
| lkcl | (b) more sensible to do 8 things of 8/4/2/1-bit wide | 17:51 |
| lkcl | (c) panic | 17:51 |
| lkcl | (d) run away screaming and join a tibetan monastory | 17:52 |
| programmerjake | lkcl, for budget-sync, do you *need* all the print() outputs? they obscure the errors that *should* be corrected... | 17:54 |
| ghostmansd | lkcl: the last one is also the one I've never met in programming before, I choose that one | 17:56 |
| ghostmansd | def tibetan_handler(gprs, fprs, mem): | 17:57 |
| ghostmansd | pass | 17:57 |
| programmerjake | embrace the typos! :) def join_monastory(): print("you meant monastery, right?") | 17:59 |
| ghostmansd-pc | lol :-D | 18:09 |
| ghostmansd-pc | it'd have been even more amazing if they sent us to monastery without writing a single function | 18:09 |
| programmerjake | that'd be relying on default arguments too much... | 18:10 |
| ghostmansd-pc | :-D | 18:10 |
| * jn sends ghostmansd-pc into a monad story | 18:26 | |
| jn | a story of monads | 18:26 |
| jn | the ideal conditions for functional programming ;) | 18:27 |
| programmerjake | having fun with monads in Rust :) | 18:28 |
| lkcl | programmerjake, while i was writing it, yes. otherwise i am completely unable to follow the code and link "what is written" to "what it does" | 19:04 |
| programmerjake | so, it's ok to comment them out now? | 19:06 |
| lkcl | programmerjake, yehyeh go for it | 19:19 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!