vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
vdamewood has joined #osdev
heat has quit [Ping timeout: 258 seconds]
netbsduser has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 252 seconds]
JupiterBig has joined #osdev
<geist>
heh
<clever>
geist: i assume youve heard about the rp2350 by now? i have plans to add LK to it once mine arrives
JupiterBig has quit [Ping timeout: 248 seconds]
<geist>
yep! I ordered one too
<geist>
it looks neat
<clever>
the option of 16mb of psram is pretty crazy
<clever>
for an MCU
<clever>
and this will be a wonky situation of supporting both M33 and risc-v on the same platform!
netbsduser has quit [Ping timeout: 252 seconds]
Matt|home has quit [Read error: Connection reset by peer]
<kazinsal>
hopefully the interconnect for the psram is faster than it was on the rp2040
<kazinsal>
8 megs on the 2040 was real nice but it was sloooow. iirc the picomem isa card that uses it is 6 wait states on an AT for any memory emulation that goes to the psram
<clever>
kazinsal: its rigged up similar to the XIP flash, so its just in the address space normally, with cache
air has quit [Quit: Client killed by user]
<geist>
my gues sis it's mostly useful for storing assets
<clever>
the only downside i can immediately see, is that the flash and PSRAM share the same QSPI bus, and it just has 2 chip-selects
<geist>
instead of working program memory
<geist>
also the atomic global monitor doesn't work on anything but local SRAM
<clever>
ah, good catch, i hadnt noticed that
<clever>
so you could put a heap in external ram, but atomics dont work there
<geist>
yah you might want to double check that but it was the first thing i looked at, could you build an actual SMP system with it
<geist>
well the local monitor should work, so atomics with a single cpu will work, but if you're trying to implement actual SMP the atomics (which uses the globla monitor) wont work on anything but SRAM
<clever>
i also noticed, the arm side, uses load/store exclusive, where you implement the retry in sw
<geist>
yep, that's classic arm atomic
<clever>
but the risc-v side, has all in one atomic opcodes, that retry on their own, and take 4 clocks per attempt
<geist>
not entirely. riscv has a few single i nstruction ones, but also load/store exclusive
<clever>
ah, maybe i missed those
<geist>
basically there's only amo<alu op> and amoswap
<geist>
but then to implement something like compare-exchange, you need the full lw/sw
<geist>
lw/sd i think
<clever>
page 290, lists how many clocks each opcode from the A extension can take
<clever>
ah yep, your right, load-store exclusive are the first 2, and take 1 or 2 clocks, depending on what the next opcode does
<clever>
and then page 291 has all of the amo opcodes
<clever>
which are 4 per attempt
<geist>
yah
<clever>
i also noticed, the main RV32I branch opcodes, are 1 clock slower, if the destination is a mis-aligned 32bit opcode
<geist>
yah that's fairly common. some of the big cores have that too
<clever>
i think the i-fetch is always 32bit aligned
<geist>
sifive cores, etc
<clever>
and under normal conditions, it will fetch half of the next mis-aligned opcode, and sort of prefetch
<clever>
but when branching, that prefetch guessed wrong
<bslsk05>
github.com: Hazard3/hdl/hazard3_core.v at stable · Wren6991/Hazard3 · GitHub
arminweigl has quit [Ping timeout: 260 seconds]
arminweigl_ is now known as arminweigl
<clever>
line 314 or decode, it looks like having `debug_mode` set, causes JAL to become an invalid opcode?
<clever>
like they want to trap any change of PC?
<geist>
yeah dunno
<clever>
and i'm not sure where i-fetch occurs, this part of the code doesnt seem to deal with it
<geist>
yeah that'll be in some other .v file i guess
<clever>
it looks like its rigging the ALU up, to add an immediate to PC
<clever>
feels like JAL is pc-relative
<clever>
and its probably raw_branchcond that will do the actual branch, to whatever the ALU spits out
<clever>
so all types of branching can just set raw_branchcond and rig up the ALU, then a common chunk of code can check the condition and maybe look at the result
<geist>
that's odd, i thought JALR would be not PC relative becuse it just branches to the target reg
<geist>
oh you know what that ADD PC stuff is? that's computing the *next* address
<clever>
yeah, thats strange, its doing the same as JAL
<geist>
to store in the RA
<clever>
oh!
<clever>
because of the L in JAL!
<geist>
ALUSRCB_IMM is probably +4 or something
<geist>
right, and the raw_rd is the target register
<bslsk05>
github.com: Hazard3/hdl/hazard3_instr_decompress.v at stable · Wren6991/Hazard3 · GitHub
<clever>
ah, branch condition is an output wire from the decoder, something else then decides what to do with it
<geist>
which is a property of riscv: each compressed instruction *must* be able to decode to a full one, so one can implement a c -> notc decoder precisely like this
<clever>
the datasheet also warned, that opcodes from the C extension can translate directly 1:1 into 32bit opcodes
<clever>
but opcodes from the Zcmp extension cant
<geist>
ie, there can't be any special case C instructions that have no equivalent (like in thumb2)
<clever>
a single Zcmp opcode, expands to multiple 32bit opcodes
<clever>
its getting CISC in here!
<geist>
oh? oh that's right. haven't dealt with those before
<geist>
they're basically embedded only
<clever>
the datasheet also mentioned, that if C is enabled, and you give it a compressible 32bit opcode, it will use the 16bit form automatically
<bslsk05>
github.com: Hazard3/hdl/hazard3_instr_decompress.v at stable · Wren6991/Hazard3 · GitHub
<geist>
that's a property of the assembler yes. you can disable it with some assembler operative
<clever>
but you can also use c.add, to force the compressed form, i assume assembling fails if the extension is off?
<geist>
yeah
<clever>
other then being slightly smaller in asm, i feel like its better to use compressible forms of the 32bit opcodes?
<clever>
then it works best in both modes
<geist>
yeah there's really no downside to using it
<clever>
`c.add a0, a1` might be smaller, but `add a0, a0, a1` is more portable, and can still benefit from C if enabled
<geist>
and compilers/assembly writers etc should be slightly aware of the situations that allow it to use the C version
<geist>
and yes, you always write the uncompressible version and the assembler can replace
<geist>
in practice it actually gets pretty good use of it, the code density of riscv + c is pretty close to thumb2
<clever>
the VPU has something similar, where the assembler will auto-compress, and gcc has been told that r0-r15 are "fast", because opcodes using those can compress
<geist>
and a lot better than arm654
<clever>
that then causes gcc to prefer using the lower half of the regs
<geist>
the main downside that iv'e seen some vendors that are implementing riscv cores (mostly ones that have previously done ARM) is the C instruction set chews up a sizable chunk of the opcode space
<geist>
since 3 whole bits are basically fixed in stone when implementing a 32bit opcode
<geist>
so i guess it chews up like 7/8th of the address space?
<geist>
well bit space
<clever>
one of the engineers also responded on the forums, about "why no usb2"
<clever>
and they mentioned that a usb2 core, takes up more die space then both hazard cores combined
<clever>
i dont know about risc-v, but the VPU variable length encoding, basically had a 1/2/3/4 bit flag in the opcode to indicate the size, something like if the first bit was 0, its a short opcode, so now you have 15bits left to play with
<clever>
if the start is 0b10, then its a 32bit opcode, so youve got 30 bits left
<clever>
so the more compressed the opcode is, the smaller the size tag is
<geist>
yah riscv has a utf8 style thing in the base of the opcode that determines how much more opcode there is
<geist>
16 bit opcodes all start with 00,01,10
<geist>
32bit opcodes all start with 011, 48 bit opcodes start with 0111, 64 01111 and so on (iirc)
<clever>
ah, thats a bit more complex
<clever>
having 3 different prefixes for 16bit opcodes
<geist>
at the moment none of the 48/64/etc space is defined
<geist>
wel the idea is the 16 bit opcodes need the bits more than 32bit, so they gave 16 a bit more to work with
<clever>
ah, thats why ive not heard of such fat opcodes
<clever>
VPU instead went for a 1bit size tag, and 15 usable bits, so thats 2^15 or 32768 possible 16bit opcodes
<clever>
while it sounds like risc-v has a 2bit size-tag, with 3 valid states, so 3 * 2^14 possible 16bit opcodes? 49152
<geist>
yah
<clever>
neat, they managed to get more opcodes, despite using a larger tag
<geist>
but then chews off more space in 32bit world
<geist>
but some of that is also not just because of the 16bit opcodes, but beause it allows for >32
<clever>
but 32bit has a lot more room to spare
<geist>
so one bit goes to 16, another goes to >32
<clever>
what do you think about arm getting an fpu and risc-v lacking one entirely?
<geist>
oh i didn't think about that
<clever>
from what ive seen, the arm has a standard 32bit float co-processor, and then a custom 64bit co-processor
<geist>
oh hmm, yeah i guess there is a difference. probably a sizable change too
<geist>
the fpu is probably very large compared to it
<clever>
the arm 32bit fpu is a standard block, so i think it has several float registers and all the usual float ops?
<geist>
yah the register file is probably fairly substantial
fedaykin has joined #osdev
<clever>
but then you have the custom 64bit co-processor, it only has add/sub/mult/div/sqrt, only 2 registers? and a 9bit status flag
<clever>
the docs mention it being far more light weight, at the cost of needing more back&forth, but still being better then doing it in software
<geist>
ah hmm, okay. that i guess keeps it fairly small
<geist>
the register f32 will have i think 32 32bit registers, i think
<clever>
yeah, thats basically doubling the register space
<clever>
and if you had 32x64bit, that would double it again
<clever>
i forget why, but you said something about the VPU's design not being good? where you just have 32 GP registers, all 32bits, and they can be int32 or float32
<geist>
oh i dunno i dont think i was dissing it much
<clever>
that seems far simpler to me, the normal function prologue and irq save/restore doesnt have to care about floats being unique
<geist>
it's an ARC iirc, right? or a derivative at least
<clever>
i forget what its based on
<clever>
ah yeah, ARC is mentioned on the github with all of the docs
<clever>
another slightly weird thing, the float64 co-processor, is doubled up, for secure and non-secure modes
<clever>
ah, there it is, co-processor 4, maps to the DCP (double precision coprocessor) for the current security status, so its easy to access
<geist>
oh side note, someone at work mentioned armv8-m (which the cortex-m33 is) has a built in stack-overflow detection mechanism
<geist>
i need to look into it
<clever>
while co-processor 5, maps to the non-secure DCP, and can only be used by secure mode, to save/restore when context switching between different non-secure guests
<clever>
so when you transition from NS->S, you dont have to worry about the DCP being tainted
<clever>
only if your S is context switching from one NS to another NS
<clever>
RPF also added their own stack canary stuff, in the redundancy co-processor
pabs3 has quit [Remote host closed the connection]
<clever>
at boot, it will generate a random seed, which is somehow used in generating and verifying stack canaries
pabs3 has joined #osdev
<clever>
its intended to ruin return orientated programming
<clever>
ah there it is, section 3.6.3.5, upon entry to a function, a canary is written to the stack frame, and its unique to both the boot (64bit random seed), and the function being entered (8bit tag)
<clever>
and then upon exiting a function, it will verify the canary is valid
<clever>
so you cant just jump into a random function, and then let its prologue pop a return addr from the stack
<clever>
the canary would be entirely wrong, and it would hard fault
<clever>
and the canary is different on every boot (the 64bit seed)
<clever>
oh, interesting, only 24bits of the canary are used, the lower 8 bits are zero, so when you store it to ram in LE32 order, that becomes a terminating null
<clever>
so a stray strcpy will die on the first byte (all nulls) of the canary, and not leak the canary itself!
<clever>
and its now 2am, i should get some sleep!
<geist>
no more Tony Hawk's Strcpy
<clever>
:D
frkazoid333 has quit [Ping timeout: 260 seconds]
Gooberpatrol66 has joined #osdev
goliath has joined #osdev
ghostbusters2 has quit [Ping timeout: 252 seconds]
ghostbusters2 has joined #osdev
fedaykin has quit [Quit: Lost terminal]
ChanServ has quit [shutting down]
ChanServ has joined #osdev
masoudd has joined #osdev
<kof673>
hmmm...game cube and xbox 360 are two things i might want that, but how much work would it be to track down a game and mem card and make a custom file/etc. :/ good to know anyways :D
air has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
<Ermine>
what P means in PSRAM?
<Ermine>
... Pseudo
<Mondenkind>
phallic
GeDaMo has joined #osdev
Yoofie646 has quit [Ping timeout: 245 seconds]
fedaykin has joined #osdev
netbsduser has joined #osdev
hwpplayer1 has joined #osdev
mavhq has joined #osdev
masoudd has quit [Ping timeout: 252 seconds]
op has joined #osdev
heat has joined #osdev
edr has joined #osdev
JupiterBig has joined #osdev
JupiterBig has quit [Client Quit]
raphaelsc has joined #osdev
JupiterBig has joined #osdev
someguy has joined #osdev
Rubikoid has quit [Read error: Connection reset by peer]
Rubikoid has joined #osdev
Dead_Bush_Sanpai has joined #osdev
<Ermine>
I wonder how hard is it to deal with stale mount points
m3a has quit [Ping timeout: 252 seconds]
someguy has quit [Ping timeout: 244 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
Ermine, what's a stale mount point
<Ermine>
heat: e
<Ermine>
e.g. you mount usb drive, then plug it off without unmounting first
<heat>
ok, then define "deal with"
<nikolar>
heh
<nikolar>
not much you can do then
<nikolar>
dump all of the caches, report errors on accesses and disappear the mountpoint
<heat>
pretty much yeah
<nikolar>
i think for fat32 (or was it for removable drives) windows automatically does direct writes to the drive
<nikolar>
no caching
<nikolar>
so you have consistent data (or as close to it as possible)
<heat>
what happens if you run zfs on a flash drive
<heat>
will it catch fire?
<nikolar>
literally nothing
<nikolar>
it will just work (tm(
<zid>
just not work*
<zid>
a) flash drives never fucking work b) nothing can read zfs
<nikolar>
nothing can read zfs???
<nikolar>
a) fair point
<heat>
aktshually i run illumos 🤓
<heat>
nikolar, dude is zfs even compatible between solaris and openzfs?
<heat>
do all systems run slightly different and incompatible versions of zfs
<netbsduser>
they have Feature Flags now
<netbsduser>
an advanced new feature pioneered by OpenZFS
<netbsduser>
this application of the sun engineering ethos (even after the sunset) ensures robust interoperability between all the heritors of the solar legacy
<nikolar>
heat: there's openzfs which should be compatible between linux and freebsd
<nikolar>
if you mean the oracle solaris, that was proprietarized the moment oracle got their hands on it and is generally not compatible unless you restrict it to the lower common denominator
<nikolar>
i am not even sure of that
Starfoxxes has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]
Left_Turn has joined #osdev
JupiterBig has quit [Ping timeout: 260 seconds]
JupiterBig has joined #osdev
eddof13 has joined #osdev
JupiterB2g has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
eddof13 has quit [Quit: eddof13]
eddof13 has joined #osdev
<heat>
two zfs? which one is the real one
<nikolar>
openzfs of course
JupiterBig has quit [Ping timeout: 260 seconds]
<nikolar>
even netbsd has a working openzfs port, though it's somewhat old
JupiterB2g has quit [Ping timeout: 272 seconds]
someguy has joined #osdev
eddof13 has quit [Quit: eddof13]
<heat>
sorry, i'm a solaris loyalist
eddof13 has joined #osdev
<kof673>
i think we have to like...threaten to execute solaris, and the real zfs will step in and stop it?
<kof673>
something like that
<nikolar>
lol
<isabella>
king solarismon?
[Kalisto] has quit [Read error: Connection reset by peer]
[Kalisto] has joined #osdev
JupiterB1g has joined #osdev
JupiterB2g has joined #osdev
someguy has quit [Ping timeout: 260 seconds]
<mjg>
nikolar: it's NOT an openzfs port motherfucker
<mjg>
it's one true zfs directly from the freebsd port, which was directly made from illumos
<mjg>
that's from before openzfs became stable
<nikolar>
oh is that so
<heat>
doesn't freebsd also use openzfs?
<nikolar>
they do now
JupiterB2g has quit [Ping timeout: 244 seconds]
JupiterB1g has quit [Ping timeout: 244 seconds]
JupiterB1g has joined #osdev
JupiterB2g has joined #osdev
FreeFull has quit [Quit: rebooting]
FreeFull has joined #osdev
Dead_Bush_Sanpai has quit [Quit: Dead_Bush_Sanpai]
JupiterB2g has quit [Ping timeout: 252 seconds]
JupiterB1g has quit [Ping timeout: 260 seconds]
op has quit [Remote host closed the connection]
hwpplayer1 has joined #osdev
freakazoid332 has joined #osdev
Left_Turn has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
hwpplayer1 has quit [Remote host closed the connection]
Gooberpatrol66 has quit [Quit: Konversation terminated!]
Gooberpatrol66 has joined #osdev
hwpplayer1 has joined #osdev
fedaykin has quit [Quit: Lost terminal]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
Matt|home has joined #osdev
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
hwpplayer1 has joined #osdev
the_oz has joined #osdev
<the_oz>
Been missing a loooooong time. But, hello!
hwpplayer1 has quit [Remote host closed the connection]
<zid>
how'd you get a colon and a number in your host
<the_oz>
/ns register
<the_oz>
shorthand for /msg nickserv register
<zid>
yea I know how irc works
<zid>
you infact, have to be registered to join this channel it's +r
<the_oz>
I never made the jump to libera.chat until just now. The number was given to me not of my volition
<zid>
afaik those cloaks were tied to org and an ircop had to do it
<zid>
never seen one with a colon number
<the_oz>
Thank you for verifying your e-mail address! You have taken steps in ensuring that your registrations are not exploited.
<the_oz>
* You are now logged in as the_oz -NickServ- You have been given a default user cloak. -NickServ- Your account name cannot be used in a cloak directly. To ensure uniqueness, a number was added.
<the_oz>
* user/the-oz:26077 :is now your hidden host (set by services.) -NickServ- Information on the_oz (account the_oz): -NickServ- Registered : Aug 16 19:48:56 2024 +0000 (1m 38s ago)
hwpplayer1 has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
<the_oz>
I dunno, maybe it's got an old registration, maybe back on freenode or oftc? I forget where this was
valerius_ has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
<zid>
ah it was a disambiguation automagic!
<zid>
mystery solved
<zid>
I'venever used an org cloak, I just register funny reverse dns hosts
<the_oz>
snowflake tidbit, my very own hash
valerius_ has joined #osdev
Starfoxxes has quit [Remote host closed the connection]
gog has joined #osdev
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
xenos1984 has joined #osdev
hwpplayer1 has joined #osdev
memset has quit [Remote host closed the connection]
memset has joined #osdev
Gooberpatrol_66 has joined #osdev
Gooberpatrol66 has quit [Ping timeout: 252 seconds]
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
the_oz has quit [Quit: Leaving]
hwpplayer1 has joined #osdev
Arthuria has joined #osdev
spareproject has quit [Remote host closed the connection]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
the_oz has joined #osdev
eddof13 has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
masoudd has joined #osdev
eddof13 has quit [Client Quit]
memset has quit [Remote host closed the connection]
memset has joined #osdev
memset has quit [Remote host closed the connection]
memset has joined #osdev
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
netbsduser has joined #osdev
randm has quit [Remote host closed the connection]
randm has joined #osdev
netbsduser has quit [Ping timeout: 258 seconds]
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
masoudd has quit [Quit: Leaving]
Left_Turn has quit [Read error: Connection reset by peer]
radens has joined #osdev
m3a has joined #osdev
JupiterBig has joined #osdev
JupiterBig has quit [Ping timeout: 248 seconds]
heat has quit [Read error: Connection reset by peer]