00:28mwk: ha, found a new v5 opcode
00:28mwk: 0xf3 <imm16> is apparently a 16-bit pc-relative call
00:28mwk: not sure about the "pc-relative" part yet...
00:59mwk: alright guys
00:59mwk: who reversed the "mpop*" Falcon v5 crap?
01:07mwk: it's batshit crazy in many interesting ways
01:11mwk: apparently, the invalid opcode trap no longer exists on v5
01:12mwk: because there are no more invalid opcodes
01:14mupuf: mwk: no more invalid opcodes :o?
01:15mupuf: they achieved 100% utilisation of the opcode space? :D
01:15mupuf: or they got rid of this useless trap feature that was wasting silicon?
01:15mwk: not exactly
01:16mwk: but 100% of the opcode space is covered by valid forms
01:16mwk: so the processor always knows how many bytes to fetch and how to decode the opcode
01:16mwk: but, in some of these forms, there are unassigned subopcodes
01:17mwk: which will usually just set the destination register to 0, and maybe some flags as well
01:18mupuf: I see
01:47mwk: karolherbst: how do you wait for a pause?
02:56Horizon_brave: hey everyone
04:02Lemmata: Hello! It looks like I'm getting soft CPU lockups which render my system unusable, Most likely due to nouveau as when I black list nouveau in /etc/modprobe.d the lockups stop and I am able to startup my computer normally. Can anyone help me out on diagnosing the issue and potentially filing a bug report?
06:15jayhost: 2D/3D acceleration supported on all GPUs". Woah
07:58karolherbst: mwk: the heck?
07:59karolherbst: mwk: maybe just a hardware bug?
08:00karolherbst: mwk: what do you mean by waiting for a pause?
08:39mwk: karolherbst: the div thing?
08:40mwk: it turns out to be my bug actually, sort of
08:40karolherbst: ohh, I see
08:40mwk: %r0 is the first register I read back from the Falcon
08:40mwk: and div is a long instruction, it doesn't have time to complete before I read the reg
08:41mwk: which is why I asked how you wait for the Falcon to pause after single-stepping
08:42mwk: or, for that matter, how you know when a breakpoint was hit
08:42mwk: in related news
08:43mwk: I'm trying to add the 6 status registers to hwtest as well
08:44mwk: without much success so far
08:44mwk: though I did nail down a few bits
08:45mwk: status #1 reveals some bits of Falcon's inner workings
08:45karolherbst: I don't wait, because I single step by hand
08:45karolherbst: usually the result is already there
08:45karolherbst: so I never see the opposite
08:45karolherbst: and I also don't get notified on a hit breakpoint
08:46karolherbst: I can read out the $pc though
08:46mwk: not good...
08:47mwk: I single step by hand as well
08:47karolherbst: well, currently I am mainly toying around with my script
08:47karolherbst: which automates tons of stuff
08:47mwk: and I'm having problems with division
08:47karolherbst: like reading out the $pc, parsing the code and so on
08:47mwk: I suppose there's something you need to monitor to figure out if shit is done already
08:48karolherbst: but I checked some div instructions as well
08:48karolherbst: and when the $pc moves to the next instruction, the last div was already executed
08:48mwk: maybe your debugger is just slower :p
08:48karolherbst: well I didn't check like immediatly
08:48karolherbst: it's a script I invoke by hand
08:48mwk: weren't you writing it in bash?
08:49mwk: well, that explains things
08:49mwk: I supppse by the time Linux starts a new process, Falcon can manage to perform one division :p
08:49mwk: I kind of hit registers as fast as possible in C++
08:50karolherbst: yeah, I still plan to write one in C/C++ with nice cli interface and everything
08:50karolherbst: currently just mainly toying around
08:50mwk: let's hope we figure out the required waits before that
08:50mwk: anyhow, status register #1 is interesting
08:51mwk: it appears to have a list of pending register writes for long-running instructions
08:51mwk: eg. it says "someone is supposed to write 16-bits to %r7, and 32 bits to %r1"
08:52mwk: AFAICT, mulu/muls, div/mod, ld are considered long-running
08:52mwk: probably iord as well, but I don't test that instruction at the moment
08:52karolherbst: never had any problems with ld to be honest
08:52mwk: wait until you write your debugger in C :p
08:53karolherbst: what does long running mean anyhow? 2-4 cycles? or is there something taking even longer?
08:53karolherbst: I meant, it was never a problem in the code I wrote for the PMU
08:53karolherbst: or does the falcon wait on reads then?
08:53mwk: it means it runs long enough that Falcon starts executing subsequent instructions
08:53mwk: nah, of course it waits for reads
08:54mwk: the whole point of this reg seems to be listing registers that you need to wait on
08:54karolherbst: do you mean 0x4c?
08:55karolherbst: or STATUS_READ in 0x200?
08:55mwk: I suppose all non-long-running instructions are so fast that the results are available immediately
08:55mwk: there are 6 different status registers
08:55karolherbst: ohhh, I see
08:55mwk: you pass the index in 0x200, like you do for normal registers
08:55mwk: and you can read things
08:55karolherbst: yeah, I know
08:55karolherbst: I do it for registers already
08:56mwk: it seems that status register 3 is what was 0x128 on Falcon v3, but with a few bits moved around
08:56mwk: status register 1 appears to be for long-running instructions, and their register writes in particular
08:57mwk: status 0 contains what I believe are the "interrupt 0 pending" and "interrupt 1 pending" bits
08:57mwk: plus something about trap handling, I think
08:57mwk: status register 4 can be used to read back the break mask
08:57mwk: and that's all I know so far
08:58karolherbst: 4 seems to be handly
08:58karolherbst: something a debugger needs
08:59karolherbst: (or it could just save it itself)
08:59mwk: the break mask is something you stored yourself :p
08:59mwk: but sure
08:59karolherbst: write ffff
08:59karolherbst: read back
08:59mwk: the break mask is in bits 16-31 of the register if you need it
08:59karolherbst: you know valid bits -> profit
08:59mwk: yeah well
08:59mwk: valid bits are ffff
08:59karolherbst: what a surprise
08:59karolherbst: and we know 3 for sure of those
08:59mwk: doesn't mean all are used
09:00karolherbst: which one as well?
09:00mwk: bit 5 is TLB_MISS
09:00karolherbst: adjust falcon.xml :p
09:00mwk: though I cannot get single-stepping traps to work no matter what I do
09:00karolherbst: yeah, I somehow failed to get the traps working as well
09:00karolherbst: reading back 0x100 is helpful
09:00karolherbst: if something went wrong, it prints out STOPPED
09:01karolherbst: basically means the falcon gave up
09:01karolherbst: the same with breakpoints
09:01mwk: I just know that bit 5 in the break mask makes TLB miss trap do different things :p
09:01karolherbst: if you set a breakpoint, but not break on it in the break mask
09:01karolherbst: the falcon stops
09:01mwk: not exactly true
09:01mwk: Falcon starts executing the usual trap handler at that point
09:01karolherbst: okay, sure
09:02karolherbst: but then the falcon doesn't halt
09:02karolherbst: and it's quite useless from a debugger point of view
09:02karolherbst: mwk: I am wondering
09:02karolherbst: mwk: maybe bit 7 isn't BREAKPOINT, but TRAP?
09:04mwk: unless it already has $ta set in $flags, in which ccaase, bye
09:04karolherbst: well, bits 0-6 and 10-31 aren't for traps for sure
09:04karolherbst: and 8 and 9 are iv0 and iv1
09:05karolherbst: mwk: I can only check it in like 8 hours, do you want to check if bit 7 in the break mask is more generic and includes _any_ trap?
09:07mwk: I already told you, bit 5 is the TLB_MISS trap
09:07mwk: so 7 definitely doesn't cover all traps
09:07karolherbst: okay, then it may cover a few traps
09:07karolherbst: maybe even the sw traps 0-3
09:07mwk: if TLB miss is separate, I suppose they all are
09:07karolherbst: not traps 0-3
09:07mwk: except maybe individual sw traps
09:08mwk: I will check TLB multi hit and sw traps soon
09:08mwk: I cannot check invalid opcode on this hwtest though
09:08mwk: stupid v5 and its fully covered opcode space
09:08mwk: I mean, "covered"
09:09karolherbst: well I can also check the sw traps, because I have the code for this already
09:16karolherbst: mwk: I think the invalid opcode may also be bit 7, because it wasn't any of the other ones afaik.
09:16karolherbst: or maybe I did something terribly wrong
10:06mwk: NFI what that's about, but $cauth bit 19 affects trap semantics *somehow*
10:06mwk: as in, it determines if bit 22 of status reg 0 is set after a software trap
10:06mwk: whatever the fuck that is
10:06karolherbst: it also affects interrupts
10:07karolherbst: I have ideas
10:08karolherbst: do you know what bit 22 is?
10:08mwk: I just know it's set on sw trap iff $cauth bit 19 is clear
10:11karolherbst: I totally forgot what bit 1 was
10:11karolherbst: ohh wit
10:11karolherbst: I remembered
10:13karolherbst: mwk: so bit 8-23 are configuration bits? I guess you don'T really know what those are about?
10:13mwk: of #cauth?
10:14mwk: bits 16, 17, 19 are some sort of flag bits
10:14mwk: 0-8 is base address, 24-31 is size, rest are unused
10:14karolherbst: yeah, I know the address bits
10:14karolherbst: ohh, okay
10:14mwk: bit 16 controls code xfers
10:15mwk: if it's set, xcld'd pages will be marked as secretful
10:15karolherbst: 8 is part of base address?
10:15mwk: and I have no idea about bits 17 and 19
10:15mwk: well, maybe an idea about bit 19
10:15mwk: it could perhaps be used to disable traps while in secure code?
10:16karolherbst: but why though?
10:16karolherbst: afaik interrupts get disabled automatically anyway
10:16mwk: so breakpoints you set before secure entry won't fire?
10:16karolherbst: or well, "reset" is the proper term I think
10:16karolherbst: no clue
10:16mwk: it definitely affects the sw traps somehow
10:17mwk: we'll figure it out later, I suppose
10:20mwk: sort of confirmed
10:20mwk: $cauth bit 19 is some kind of master interrupt/trap disable
10:21karolherbst: how can you even confirm this?
10:22mwk: status reg 0 bits 23 and 24 are "interrupt 0/1 pending", respectively
10:22mwk: if I set $cauth bit 19, these are forced to 0
10:22karolherbst: I see
10:23mwk: also, the sw trap thing doesn't set bit 22
10:23mwk: which I'm starting to think is a "trap pending" bit
10:23mwk: I think sw traps are executed in two phases
10:24mwk: the first single step you do steps $pc over the sw trap and writes $tstat register
10:24mwk: and sets the "trap pending" bit
10:24mwk: but then you need a second single step to actually enter the trap handler
10:25karolherbst: this makes sense
10:25mwk: ie. push old $pc, load $pc from T$tv, set $flags.tv etc.
10:25mwk: probably all traps are executed in two phases like that, matter of fact
10:25karolherbst: the falcon always halts at the instruction _after_ the trap
10:25mwk: look at status reg 0
10:25karolherbst: can't do it from here
10:26mwk: bit 22 should be "a trap is pending instead of executing the next insn"
10:28mwk: and uh
10:28mwk: here comes strangeness
10:28mwk: I think the "is interrupt X enabled" signal is delayed by one instruction or something like that
10:29mwk: so eg. you could get an interrupt immediately after a "bclr $flags ieX" instruction
10:30karolherbst: I doubt this
10:30karolherbst: I think the hw needs a cycle to setup the interrupt handler/stuff
10:30karolherbst: but then it fires those immediatly
10:31mwk: well, there are the "interrupt pending" bits in stat 0
10:31mwk: and they're based on $flags.ie* from *before* the last single-stepped instruction
10:31karolherbst: yeah, that makes sense
10:31karolherbst: ohh okay
10:31karolherbst: yeah, makes sense
10:31karolherbst: I saw this behaviour as well or at least it explains what I observed
10:41RSpliet: hmm... I guess I'll get in trouble with DDX maintainers if I change the notation of ops in envydis to always include the return type
10:45mwk: which ops?
10:45RSpliet: stuff like imad (which is shown as e.g. add $r2 (mul s32 $r0 s32 c0[0x30]) $r5 - but doesn't explicitly state it does a signed addition)
10:46mwk: uh... it doesn't?
10:46mwk: addition doesn't really come in signed/unsigned variants
10:47RSpliet: I thought it had some influence on how to calculate overflow flags...
10:47mwk: the overflow flag is always signed overflow, the carry flag is always unsigned "overflow"
10:48RSpliet: hmm, convenient
10:50RSpliet: still, my purpose is to quantify the ratio between mem ops/integer arith/fp arith/... so a more regular output format would help me regardless of whether the information is redundant. Guess I don't have to upstream that stuff really
10:51mwk: tbh having the type as an instruction modifiers was one of my bigger mistakes in envydis
10:51mwk: it really should have been add vs fadd vs dadd, not add b32 / add f32 / add f64
10:52RSpliet: would've been nicer to write asm that way I guess... but as a reader I don't mind either
11:05karolherbst: sell it gets fun with instructions having seperate dType and sTyper
11:08mwk: here's what I know about status regs so far
11:10RSpliet: mwk: I'm not sure if meh.c and nes.c exist
11:11mwk: oh fuck me.
11:11mwk: I knew I shouldn't do CTFs and production work in the same git clone...
11:13karolherbst: mwk: https://github.com/envytools/envytools/commit/bdc84dc1b41b267c32eb9296c6e23dd25314927e#diff-c7ef2321ed59046ae536c78d8e91b6c8 and dis-intern.h
11:14karolherbst: we should configure travis-ci to leave a message here on failed builds
11:19karolherbst: it would be too easy travins being happy now
11:19karolherbst: check_rnndb fails
11:20karolherbst: I think I will mod the travis-ci file to 1. leave a message here and 2. printing out details about failing tests
15:37smusiland: Allah is doing
15:38smusiland: aaronp: abff aboll adsworth chithead specing
15:54RSpliet: Is it me who sucks at writing OpenCL kernels, or is the arithmetic in those things heavily dominated by integer operations? (like 60-80% of all ops)
15:54RSpliet: sorry, 50-75% is a more accurate band
15:56karolherbst: RSpliet: I think this is normal. Also OpenGL compute shaders contain more integer operations than any other
15:59RSpliet: Yeah I bet it's the same for Cuda... just lots of pointer hymnastics
16:00RSpliet: I guess it all pans out nicely if int arith is a fraction of the cycles (throughput) of fp. If you dual-issue, you'll need about as many ALUs as FPUs (... but do they share hw? hmm...)
16:02mupuf: RSpliet: are 32 bits ALU that big, area-wise, compared to an FPU?
16:02RSpliet: mupuf: an FPU is, ignoring a lot of details, a wide ALU with preshift/postshift logic
16:03RSpliet: multipliers are just big, whether FP or int
16:07specing: multipliers can be small if you allow them to take word-size cycles
16:08specing: basically shift + add
16:08specing: they are only huge if you want them fast
16:10mupuf: word-size cycles_
16:11karolherbst: 32 cycles for 32bit values?
16:11karolherbst: I think
16:11mupuf: ah! Right!
16:15specing: it gets more complicated the faster you want it done
16:16specing: so instead of 32 cycles you can have a reasonable trade-off at 4 or 8 cycles
16:16specing: depends on application
16:16karolherbst: is it even possible in one cycle?
16:17specing: and you can do OoO execution where mul timing doesen't matter that much anymore (as long as mul time < average number_of_all_instructions/number_of_muls in a program)
16:18specing: since other stuff can execute simultaneously
16:18karolherbst: well sure, but I meant without OoO tricks and being able to do them one after each other infinitly
16:22RSpliet: specing: that logic no longer applies if you wish to allow pipelining
16:29RSpliet: supposedly a clock of 1.5GHz is too high for a full multiply, but chop a 3-2 reduction variant of 33x32 (mul+add) up into four and you still have a multiply-add unit that can work at a rate of 1CPI. For an addition, multiply one of the operands with 1 (if you do it cleverly, you can skip some pipeline stages if design permits), for a mul, set the add operand to 0. That way, you'll save hw on not building a separate adder ;-)
16:32specing: RSpliet: sure it does, but the pipelining is localised to the execution unit
16:32specing: OoO is scheduler basically
16:33RSpliet: Yes, they're orthogonal. as far as I know NVIDIA GPUs are in-order issue, out-of-order execution
16:34specing: well much more than a scheduler, also a dependency tracker
16:35RSpliet: ~8 hw threads per (fp) execution unit (simplification) - which is why they'd be able to exploit this kind of pipelining despite having in-order issue
16:35smusiland: Allah is doing
16:36specing: Someone made a processor that includes a kernel in hardware that has 8-32 threads per core
16:36smusiland: Sun is not doing, allah is doing
16:37RSpliet: Niagara springs to mind... but surely there's been lots of research-work since
16:37specing: but yes, 8 threads means 8 cycles per instruction which is basically very easy to work with as a hardware designer
16:38specing: RSpliet: https://github.com/azonenberg/antikernel
16:39smusiland: Skies are not doing, allah is doing
16:40mupuf: who has banning powers? This is getting old
16:41RSpliet: back to the original point. If I have to make an arsepull estimate (I'm not experienced on the physical level) I'd say you can do a pipelined multiply-adder in CMOS in 30,000 transistors... that could have been 3KB of SRAM. NVIDIA has 3500 of them on high-end chips, which'd be idk... half a percent of their budget?
16:42smusiland: You can't ban without Allah permission
16:42smusiland: You can't die without Allah permission
16:42smusiland: Computer is not doing, allah is doing
16:42specing: and you can't get his permission when he doesen't exist
16:42specing: must be so frustrating
16:43smusiland: You can't write without Allah permission
16:43smusiland: Allah has the power
16:43smusiland: Everyone have to listen to Allah
16:44smusiland: JHON CEEENNAAAAA
16:44smusiland: ALLAH U AKBAR
16:45smusiland: You can't ban without the permission of Allah!!
16:45mupuf: specing: yeah, I tried feeding the troll yesterday, it did not get anywhere. The guy is obviously not a bot and has nothing else to do than spam people with fake religious message
16:46smusiland: You can't be nigger without the permission of Allah
16:46smusiland: You can't follow non-islam religions withoit the permission of Allah
16:47mupuf: for fuck sake, good bye!
16:47smusiland: ALLAH U AKBAR
16:47RSpliet: mupuf: keep it rated for general audience here ;-)
16:48mupuf: yeah, he definitely achieved his goal
16:48smusiland: You can't be jewish without the permission of Allah
16:49smusiland: You can't drink alcohol without the permission of Allah
16:50smusiland: You can't ban smusiland without the permission of Allah
16:51smusiland: Maometto couldn't gain the power without the permission of Allah
16:52smusiland_: Allah is doing
16:53smusiland_: mupuf can't ban smusiland without the permission of Allah
16:53mlankhorst: ban his account too: $a:musiland ?
16:53Lyude: wow, it appears we have been "Trolled"
16:54mupuf: Lyude: yeah, he started yesterday already
16:54specing: notice how the uid never changes?
16:54mlankhorst: was thinking more using his freenode login
16:54Lyude: mupuf: it is weird to me people still do that stuff on irc
16:55RSpliet: markov chains get bored
16:55mupuf: specing: yes, saw it
16:55mupuf: I banned one guy by mistake and I am reading up on how to invite him back :s
16:56mupuf: wasting time...
16:56specing: collateral damage
16:56robclark: hmm, is martm also chatter?
16:57RSpliet: !mode +b $a:smusiland
16:57mupuf: RSpliet: why are you adding him back?
16:57RSpliet: mupuf: +b ban, -b undo ban
16:58whydoubt: robclark: yes, I've seen martm elsewhere
16:59mupuf: that should make sure he can come back
16:59robclark: yeah, he showed up briefly on #freedreno a few minutes ago..
16:59mupuf: and I sent him a pm
17:01RSpliet: there... that'll probably keep $troll entertained for a good 15 minutes. Now carry on as if nothing happened folks
17:42Tom^: indeed , the uid doesnt change unless he changes account on irccloud.com . https://www.irccloud.com/abuse "The ideal ban mask for banning a specific IRCCloud account is: *!*id12345@*.irccloud.com"
17:44mupuf: Tom^: thanks for the info :)
17:50karolherbst: who is OP by the way?
17:51Tom^: uhm the owner of the channel you mean?
17:51karolherbst: besdines that person
17:52Tom^: marcheu: created this channel 11 years ago
17:52Tom^: it seems, /msg chanserv info #nouveau
17:52karolherbst: I actually expected serious answers :D
17:53Pie_Mage:goes back to endless idling
17:54Tom^: karolherbst: yeah if you have op or "permissions" just run /msg chanserv flags #nouveau and it will list them
17:54Tom^: i dont :(
17:54RSpliet: which... reminds me. Maybe time to break a little tradition
17:54Tom^: what changed?
17:55Tom^: or am i blind :D
17:55karolherbst: ilia will be sad now
17:55karolherbst: Tom^: well I can't check the flags
17:56Tom^: perhaps it requires some flag to be able to see it aswell
17:57karolherbst: no clue, I have no idea what is going on regarding this anyway
18:05pmoreau: RSpliet: You could have the logs URL be: https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau
18:35karolherbst: mwk: bit 0 is something memory related
18:36karolherbst: mwk: maybe even something like "droped below last assignment"
18:36karolherbst: but I think this is a simple memory watchpoint
18:36karolherbst: or rather "sp was set to X"
18:39karolherbst: or something else
18:40karolherbst: got a breakpoint at ld b32 $r13 D[$r14+0x4])
18:40karolherbst: where $r14 is 0x80000000
18:41karolherbst: mhh, this doesn't make much sense
18:45karolherbst: but I am sure it is something memory related
19:00mwk: bit 0 of what?
19:00mwk: break mask?
19:53mwk: karolherbst: have you, by any chance, figured how the two continue types differ?
19:55karolherbst: mwk: what do you mean by that?
19:55mwk: there are 4 different continue commands
19:55karolherbst: I remeber
19:55karolherbst: kind of
19:56karolherbst: I mean, I know what the _from_addr things do... but I think you asked about the unk both
19:56mwk: they are clearly two pairs of "continue from current PC" and "continue from new PC"
19:56mwk: but I have no idea how the pairs differ
19:56karolherbst: I have an idea
19:57mwk: please tell
19:57karolherbst: maybe the one skips the exectuion of stuff in between and the other not?
19:57mwk: what kind of stuff?
19:57mwk: what would be the point of executing instructions if you don't want to execute instructions?
19:58karolherbst: mhh true
19:59karolherbst: maybe something like execute next after pc/addr or execute instruction at pc/addr? but that would be pointless as well
19:59karolherbst: I didn't really looked much into that
20:02mwk: I think we're both idiots
20:02karolherbst: most likely something super trivial
20:02mwk: I can't find the commit where it comes from
20:02mwk: but I snatched this little thing from gk20a driver
20:03mwk: before they cleaned it up
20:03karolherbst: well, afaik they are still all continue commands
20:03mwk: and grep for _icd_
20:04mwk: "run" and "runb", whatever that means
20:05karolherbst: mwk: maybe clear break_mask?
20:05mwk: that wouldn't exaclty be useful
20:05mwk: besides, it appears they call it "emask"
20:05mwk: now I also wonder what "sbu" does...
20:06karolherbst: uhh, all special regs are there as well
20:06mwk: just their names
20:07karolherbst: the break_mask is there as well
20:08mwk: 1 bit for every trap
20:08mwk: + 1 bit for every interrupt, all *3* of them
20:09mwk: I still want to know what's the fucking deal with iv2
20:09mwk: by all rights, it should not exist
20:10karolherbst: I really dislike how they name all those things
20:10karolherbst: and probably use it as well
20:10karolherbst: shouldn't that look like super ugly in code?
20:11karolherbst: probably they used a lot of macros to let it look nice in the end?
20:11mwk: it's quite horrible, yes
20:12karolherbst: I am wondering why those trap breakpoints didn't hit for me
20:14mwk: try using the other continue
20:14karolherbst: I never used one in those tests to begin with
20:14karolherbst: I just put the trap into my common code and setup 0x200 on the falcon
20:15karolherbst: maybe things are different if you are inside a interrupt handler?
20:17mwk: how would the ICD even know that?
22:03mwk: eh, the 0xf3 opcode is weird
22:04mwk: it seems to just be an absolute 16-bit call
22:04mwk: should be redundant with f5 21
22:23mwk: ok, it's not redundant with f5 21 - they removed f5 21
22:24mwk: still, NFI why they bothered to make an all-new 16-bit call instruction
22:31mupuf: mwk: is it really all new?
22:35mwk: the f3 opcode?
22:36mwk: I mean, I haven't recently verified it doesn't exist on v4
22:36mwk: but I've never seen it before
22:37mwk: and Falcon doesn't have truly duplicate opcodes, so the fact that f5 21 exists on v4 strongly suggests that f3 doesn't
22:43mwk: eh what the fuck
22:44mwk: if you have $pc pointing to an unmapped page while $cauth bit 19 is set, Falcon just increments $pc by 1 and sets $r0 to 0
22:45mwk: matter of fact, it always increments $pc by 1
22:45mwk: even if it triggers a trap
22:45mwk:wonders wtf happens if an instruction is partially on an unmapped page