<geist>
ah. yes. there's rationale for it, but the immediate packing in riscv is wonky
<geist>
it's set up so that there's actually a minimum number of combinations. ie, when bits show up they show up in the same place in all forms of the instruction
<geist>
thus keeping the nmumber of interna muxes down
<geist>
and for example the sign extend bit is always in the same spot
<zid>
and your jumps are super limited :P
<zid>
13 bits should be enough for anybody
dude12312414 has joined #osdev
hrberg has quit [Ping timeout: 255 seconds]
<heat>
print(hex(~0x100000 + 1))
<heat>
>-0x100000
<heat>
THANK YOU
<heat>
VERY USEFUL PYTHON
<klange>
python has unlimited precision for ints, what do you want it to do, infinitely loop printing Fs?
<heat>
i just want an ez way to look at 2s complement of numbers
<moon-child>
usually I just do 0xffffffffffffffffffffffffffff & whatever
<heat>
oh, cool trick
<heat>
i wanted to check if my jump ranges were correct, which i think they are now
hrberg has joined #osdev
<zid>
heat you should learn C
<zid>
It's way easier than making python do bits
<moon-child>
apparently there is a thing in java where because it doesn't have unsigned integers, if you want to store an unsigned 8-bit integer, you have to store it as a signed 8-bit integer
<moon-child>
so then to zero-extend you have to say 0xff & whatever
<moon-child>
they also have a special unsigned right shift thing and I think some magic intrinsic functions for unsigned compares (since zero extend doesn't work for longs)
<heat>
]-1MB - 1, 1MB[ looks like my jump range
<moon-child>
because 'unsigned integers will be confusion' -James Gosling
<heat>
zid, i dont want to write a bunch of boiler plate for that
<heat>
boilerplate*
<zid>
'boilerplate'
<zid>
printf
<heat>
moon-child, fun fact lots of important C++ people are explicitly disavowing unsigned
<zid>
unsigned is pretty bad
<heat>
and size_t for container sizes
<heat>
they want fucking signed container sizes because who'd need a big container!
<moon-child>
I disagree with them, but I can see the argument
<zid>
It's basically the same as the 'char' problem, there's no way to signal error cases reliably, easy to confuse 0 for invalid or valid but == 0 etc
<moon-child>
however I think even they would agree if you have a bunch of integers in [0 255] that you should store it in a uint8_t*
<moon-child>
or fuck who knows std::vector<std::uint8_t>
<zid>
the char problem being "you use int so that you have space for EOF"
<zid>
yea it's *very* rare you're actually dealing with chars as uint8_t's in practice I feel though
<bnchs>
moon-child: what are you doing
<moon-child>
errr an std::vector<std::uint8_t>& ?
<zid>
except for like, file parsers
<moon-child>
bnchs: right now? I am wrestling with the fact that mach-o is a stupid piece of shit
<bnchs>
what are you doing, no stop, oh god, no std::vector
<heat>
std::vector is good
<heat>
THE C GANG WRITES A REALLOC LOOP FOR THE 400TH TIME
<heat>
Now With Reallocarray Included!
<bnchs>
bro shut up and use talloc
<bnchs>
talloc gang
<moon-child>
did you know they put strings in .text?
<zid>
now if only std vector didn't look like an alien fetus growing out the side of the head of the language
<zid>
.rodata and .text are the same thing in most linux distros tbf
<heat>
yep
<heat>
GNU ld only got support for separate rodata and text *relatively* recently
<moon-child>
yeah but it's about the principle of the thing
<zid>
gotta piss with the cock you got
<moon-child>
also because it's legitimately making my life slightly harder, because I don't know what's actually code and what's not
<heat>
did you know PE file relocations literally just poke .text?
<moon-child>
also elf has SHF_EXECINST
<moon-child>
heat: oh yeah doesn't like every dll get a random preferred address, and they hope they never collide, and run fixups if they do?
<zid>
yer
<zid>
in practice it works kinda okay?
<zid>
just means you can guess the base address of your dll, stick the 'normal' address into .rdata
<zid>
and if it loads where it should, no need to rewrite all the pointers
<heat>
geist: moon-child: aha, here's a funny fact: gcc does not split riscv functions into hot or cold
<heat>
probably due to the range limits
<zid>
how do you make it do that normally? gprof? annotations only?
<heat>
i was just using a rando's __attribute__((cold)) text
<heat>
s/text/test/
Hammdist has joined #osdev
<moon-child>
how many bits does riscv give you again? Could do alternating hot/cold pages if it's not too anemic
<bnchs>
1-bit
<heat>
20
<moon-child>
oh that should definitely be enough for that then
<moon-child>
does riscv let you do big pages?
<heat>
alternating hot/cold would require linker support that does not exist
<zid>
a megabyte is enough for anybody
<heat>
yes
<zid>
*stares in 50MB of .exe*
<moon-child>
yet another example of stable binary formats holding us back. (Ok, you _could_ bolt this on in a backwards-compatible way, but the need to coordinate and mess around with serialisation formats adds a lot of unnecessary friction.)
<geist>
moon-child: yes, re: big pages
<moon-child>
how big do they go?
<zid>
how big do you want bb
<moon-child>
when it comes to pages, I'm a size queen
<zid>
My pages go all the way from A to Z
<heat>
moon-child, 512GB
<heat>
seriously
<moon-child>
oh, wow, ok. So unfortunately you'd have to stop at ~1mb pages
<heat>
oh shit SV57 even has 256TiB pages
<moon-child>
(+/- 0.5mb displacement, and always within 0.5mb of a cold page; put a trampoline in the cold path if necessary)
<zid>
what if you need
<zid>
a meg of bounce pages
<zid>
in the middle of your binary
<zid>
.textlow (some crap) .textbounce (some crap) .texthigh and you generate a bunch of calls from textlow to texthigh
<moon-child>
otoh maybe you have one massive page for all your code, don't worry about itlb, and just do cache
<zid>
what happens when you get to 3MB of bounces
<zid>
do you need to go RECURSIVE BOUNCING
<heat>
geist, how expensive are riscv nops on real hw atm? negligible?
<moon-child>
FUUUUUSION
<zid>
riscv is accelerated on hw?
<zid>
I figured it'd take the same time as an add
<heat>
the linux code is 1) wrong 2) doesn't handle > 1MB jumps
<geist>
has a weird thing where it fetches 36 bytes instead of 32 for instruction decode but i'm guessing thats so it can fuse across a boundary
<geist>
i think this and other riscv designs are very heavily tilting towards instruction fusing. kinda makes sense in a certain way: instead of having more specialized opcodes, fuse a lot of 2 instruction sequences, as if it were a kinda new instruction
<moon-child>
it makes sense when you impose a large number of very artificial design constraints that don't actually help move anything forward
<zid>
well, it's more like
<zid>
when you steal a free teaching ISA with a number of very artificial design constraints so to be teachable
mavhq has joined #osdev
<zid>
and decide to try make it.. run code
<geist>
i think the big argument now is whether or not the compressed instructions are a good idea going forward, since they chew up a sizable chunk of the opcode space
<geist>
zid: i dont think that's particularly fair, a large number of the riscv decisions are explicitly *not* about teaching as much as building efficient implementations
<geist>
and they definitely learned a bunch from past mistakes
<zid>
geist: the people who have hold of it are massively changing it yea
<zid>
but that's why they're having to do that
<heat>
geist, i missed the joke
<geist>
heat: that there is real hardware
<zid>
because it was designed as a teaching arch, to be as orthogonal as possible to the detriment of all other things
<geist>
to test nop performance on
<heat>
i mean, you have one?
<zid>
so a person could realistically learn it in a class
<zid>
(I have a logisim riscv that fits on a piece of paper)
<moon-child>
I haven't looked at the riscv encoding specifically; others have looked at it and found some good things and some bad things. Broadly speaking for a high-power thing you definitely want compact instruction forms, and I hear riscv-c generally gets pretty good density
<geist>
sure but it being simple does not mean it's exclusively for teching purposes
<zid>
No, you can do anything with anything
<zid>
But that is why it was originally made
<moon-child>
so I'm gonna hazard that riscv with compressed instructions is better than without
<zid>
and why they're having to *adapt* it to other uses
<zid>
with comittees and extensions
xenos1984 has joined #osdev
<geist>
moon-child: it's all tradeoffs as to whgether or not the opcode space could be used more effectively, and whether or not the complexity of the compressed forms are worthwhile in the long run
<geist>
especially since the compressed forms are more or less fixed now, there's not really any space to add more bits to it
<zid>
I wannt know what happens if you design a huffman compressed cpu
<moon-child>
I think that's been done
<moon-child>
or something like that
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<heat>
it seems like llvm actively avoids splitting asm gotos and their targets on arm64
<heat>
when doing machine function splitting
<heat>
safe to say it's not a problem I think
[itchyjunk] has quit [Remote host closed the connection]
<geist>
this zuluscsi board seems to work great
<geist>
pop some files on an sd card formatted fat32 or exfat named hd0.img, cd1.img, etc and pop it in a scsi host
<geist>
picks it right up as a bunch of scsi drives
<kazinsal>
neat
<kazinsal>
will have to get one if/when I get this vax working again
<kazinsal>
relegate the scsi2sd to the macintosh I also need to recap
<kof123>
what are the macintosh specifications? i mean cpu/ram/etc.
<kof123>
what i really mean is does it run beos <runs>
<geist>
noice, yeah i have another scsi2sd that works great on my mac plus
<zid>
Would anybody like some cursed knowledge?
<moon-child>
of course
<zid>
Jello isn't boneless.
<kazinsal>
the one I have that needs the caps for the sound area redone (and maybe the floppy controller, or I could just have a bad batch of disks that won't format) is a classic ii
<kazinsal>
fun little machine, though it would have been nice to have gotten an SE/30 instead for the PDS slot
<kof123>
all this fusing talk already made me decide to allow, for an interpreter, 1) chaining multiple operations that have similar operands 2) allow chaining operations with arbitrary operands (not sure this serves any purpose, 1) is slightly more succinct) and 3) basically a for loop instruction that just chains other instructions for the 4 positions (the former 2 fusing things are allowed)
<kof123>
so...i hit my cursed quota for the day
<kof123>
compilers are not needed, just make an instruction set that handles each operation
<Ermine>
You mean tatoo? Tatoos bad (unless they can be removed)
<gog>
hhhhhhhhhhhhhhhh
<zid>
or they say unregistered hypercam 2
<Hammdist>
I made some progress on my golang environment today. a simple program that reverses a linked list in a loop by creating new elements ala purely functional programming (thus causing gc work) seems to run OK now
<zid>
I'm just sad I missed out on my childhood dream
<heat>
Hammdist, nice
<heat>
btw please explain your kernel
<heat>
im very curious
<heat>
how many pieces did you bring in? how hard was it?
<zid>
chimeraos
<heat>
chimera at least keeps linux intact
<zid>
depends if you consider having your head cut off and grafted to another animal
<zid>
'intact'
<Hammdist>
my main .c file that I wrote myself is around 1300 lines so it's pretty compact. it cuts a lot of corners, doesn't implement anything by the book but only minimally what is needed to load and run go programs. so for example pages can only be unmapped or mapped rwx. I pulled in some utility functions from other projects like cache flush etc those
<Hammdist>
are in other files. so far the golang environment only works in QEMU next step is to get it running on the actual hardware
<heat>
wait, you can load go programs in 1.3K lines?
<heat>
that's pretty impressive
<zid>
pfft my OS can load gameboy programs in that
<zid>
you neer fawn over me though
<nikolar>
does anyone here know how to create a device file for a disk
<zid>
losetup + mount
<nikolar>
i made the tinyiest linux "disto" i could but i don't know how to access the drive
<heat>
oh
<heat>
mount devtmpfs
<nikolar>
i have it
<nikolar>
it's unpopulated
<heat>
did you enable devtmpfs??
<Hammdist>
mknod can "make" the device file if you know the magic numbers
<heat>
in your kernel config
<nikolar>
yes
<heat>
it should not be unpopulated
<heat>
that's pretty bizarre
<nortti>
did you compile it with storage drivers?
<nortti>
aiui you need at least scsi on modern linux to do anything
<zid>
Oops, it looks like something's gone wrong! Would you like to submit a crash report to Al Viro?
<zid>
side note, it's kinda weird how partitions get devices
<zid>
in linux
<nortti>
(the ATA option is a trap, it's for the old /dev/hd* stuff. the modern one goes through SCSI)
<nikolar>
oh right
<nikolar>
i don't have scsi i think
<nikolar>
and by unpopulated i meant by disk devices
<heat>
lol
<heat>
you absolutely need SCSI
<zid>
not having the bus driver kind stops the bus working quite effectively
<heat>
how do you not have /dev/null btw?
<heat>
oh ok
<heat>
yeah you need scsi and libata
<zid>
heat who makes dev/sdb1?
<nikolar>
udev ?
<zid>
ah
<heat>
hm?
<heat>
who makes /dev/sdb1 in what sense?
<zid>
it has to be created via scanning the real device, /dev/sdb
<zid>
and finding partitions
<heat>
the kernel does
<zid>
huh
<heat>
there's even a funny ioctl for partition rescanning
<zid>
I mean, I guess it makes sense, but it just 'feels' like the wrong layer
<nortti>
are you surprised that in linux, kernel does stuff?
<nikolar>
kek
<zid>
I'm more surprised when there isn't some arcane project required for a thing to work
<nikolar>
rebuilt with scsi, still only tty/pty devices in /dev
<zid>
ahci?
<nikolar>
am i supposed to mknod /dev/sda or something
goliath has quit [Quit: SIGSEGV]
<zid>
pci-e?
<heat>
check dmesg
<heat>
dmesg | grep sd
<nikolar>
nope
<nikolar>
nothing
<zid>
nothing scsi got seed then, pci-e?
<zid>
if your scsi controller is on a pci-e bus, that's sort of required too, ofc
<nikolar>
is pci-e required for sata?
<nikolar>
i am testing in qemu btw
<heat>
... yes
<nikolar>
oh right yeah
<zid>
yes
<zid>
5418:00:00.0 SCSI storage controller
<zid>
need one of these
<zid>
to actually talk to the drives with
<zid>
"Good news, I now speak SCSI" "Great, what's the place we're sending the SCSI commands?" "What do you mean?"
<nikolar>
well addind pci doesn't help
<nikolar>
dmesg says it's initializing some pci devices
<nikolar>
no mention of scsi/sata
<zid>
lspci?
<zid>
e779:00:00.0 SCSI storage controller: Red Hat, Inc. Virtio 1.0 console (rev 01)
<zid>
Kernel driver in use: virtio-pci
<heat>
did you add libata too?
<Hammdist>
now after a small fix it's working on the physical board too ... but it takes 22s for the program to run on the board versus only 14s in QEMU. I thought it would be faster on the hardware (maybe not by a lot but still faster), oh well
<heat>
depends on the code and the board
<heat>
but it should be faster yeah
<zid>
Pretty sure I can emulate riscv faster than a riscv can run
<zid>
like, maybe even 10:1
<Hammdist>
well there is room for optimization in my code, for example I currently do full tlb flush for every modification
awita has quit [Remote host closed the connection]
<nikolar>
yeah no disk devices
<nikolar>
pci and scsi are initialized on boot though
linear_cannon has joined #osdev
[itchyjunk] has joined #osdev
<zid>
is there a possibly that i'm pegrent?
<gog>
pregonte
<gog>
pregonate
<heat>
proger
gog is now known as pog
<pog>
pogonate
<heat>
Ermine, hey you made me find a bug in perfetto
<Ermine>
I thought that it works with build_toolchain when you told it to me
<Ermine>
dumb me
divine has quit [Ping timeout: 245 seconds]
not_not has quit [Quit: Lost terminal]
goliath has quit [Ping timeout: 248 seconds]
goliath has joined #osdev
divine has joined #osdev
<Ermine>
Well, this time it worked. So, fedora, fuck you! linus_showing_finger.jpg
<ChavGPT>
fedora?
<Ermine>
Or redhat maybe, if fedora's gcc turns out to be rhel's gcc
<heat>
ChavGPT wouldn't know anything, he uses freebsd
<heat>
right??
<heat>
hold on... no one uses freebsd? really?
<heat>
huh
<Ermine>
I don't use freebsd and know less than ChavGPT
goliath has quit [Ping timeout: 246 seconds]
<ChavGPT>
Ubuntu 22.04.3 LTS \n \l
<ChavGPT>
:X
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<ChavGPT>
heat can we be excellent to each other for a change
<ChavGPT>
taking apage from linux' code of conflict
<heat_>
yes
<heat_>
hi how are you
<ChavGPT>
hello friend im fine thanks
<ChavGPT>
how is onyx going
<heat_>
its going ok
<ChavGPT>
only ok? sorry for asking
<heat_>
i messed around with dtrace but screw that
<heat_>
now im doing some vfs page cache refactoringggggggggg
<ChavGPT>
trace events in vm?
<ChavGPT>
trace_vm.json?
<heat_>
yeah i did that just cuz
<ChavGPT>
what is going on here
<heat_>
wdym
<heat_>
i describe events in a json format and have a python script to unfuck that into generated header+source files as part of the build
<heat_>
it is *horrendous* but im kinda proud of it anyway
<ChavGPT>
noice
<ChavGPT>
better than no tracing
<heat_>
linukz does some sort of weird C preprocessor tricks that i do not understand
<heat_>
multi-stage header parsing
<heat_>
it's really fucked up
<ChavGPT>
no bad mouthing linukx
<Ermine>
Finally, built onyx once again
<ChavGPT>
imagine if a linuks develoepr was on the channel
<Ermine>
You both commit to linux, no?
<ChavGPT>
what
<Ermine>
what
<heat_>
funnily enough i've never committed to linux
<ChavGPT>
i have some patchen but i would not reduce myself to a rank of a linux dev
<heat_>
i've sent patches but they never got merged
<heat_>
it's kinda annoying
<ChavGPT>
freel free to call heat a linux dev
<ChavGPT>
really?
<ChavGPT>
not even one?
<heat_>
yeah
* ChavGPT
chekkz
<Ermine>
lol
<bl4ckb0ne>
inb4 heat is the bcachefs dev
<Ermine>
Not even that one which got highlighted on lwn?
<ChavGPT>
that was reworekd
<heat_>
one was some elf bug fix that kees thought was too refactory and scary, second was a fix to an obscure acpi interface that the maintainer never got merged so i assume they give 0 fucks, third was the O_DIRECTORY bug that they rejected into "WAIT, LETS BREAK ALL RULES AND BREAK USERSPACE"
<ChavGPT>
WHOA THERE YOU ARE NOT LINUX TORVALD YET
TheCatCollective is now known as CalculusCat
<heat_>
i would not dare to place myself as high as mr linux himself
<zid>
Just saw a fred dibnah clip being passed around, now I'm sad cus he's dead
<Ermine>
Does build_toolchain.sh need kernel.config? Workflow file makes it for toolchains
<heat_>
Ermine, may need it for install-headers? i'm not sure
gog has quit [Ping timeout: 248 seconds]
<Ermine>
Okay, will check tomorrow
<ChavGPT>
heat_: change your cloak
<heat_>
@kernel/obnoxious_cunt/heat
gog has joined #osdev
<ChavGPT>
ok mjg@
<heat_>
wait, this is mjg??
<heat_>
wtf
<ChavGPT>
HAHA BAMBOOZLED
<ChavGPT>
this is joel spolsky
<heat_>
hi joel what do you think about software
<ChavGPT>
thank you for an excellent question
<ChavGPT>
i think software is solved by stackoverflow
<kof13>
solved as in fixed
<kof13>
fixed as in neutered
<heat_>
closed as in duplicate
<ChavGPT>
or a bad question
Matt|home has joined #osdev
CalculusCat is now known as TheCatCollective
<Ermine>
heat_: made a draft PR, you may want to stop CI as this PR is about docs
<heat_>
i don't care about stopping CI
<ChavGPT>
OH
<heat_>
may big tech forever dwell in building my system many times
<Ermine>
Well if they don't limit hours...
<heat_>
they do not
<heat_>
for public projects
<heat_>
i'd be broke when nightly's LLVM needs to rebuild
<ChavGPT>
by wasting their time you are convincng them to start dong it
<heat_>
those builds enable LTO which means 8-10h
<netbsduser`>
does anyone have any resources on netware's architecture? other than the useNix paper from 94
stolen has quit [Quit: Connection closed for inactivity]
<geist>
netware as in the classic version?
<kazinsal>
mmmm, IPX
<geist>
i remember running it a few times as part of a testing job. classic network was somewhat like banyan vines, IIRC, in that you booted into DOS and then ran the netware.exe that took over the computer
<geist>
was't that interesting on the console, just had a status screen without much to say
<geist>
but what i dunno is what it did internally, as you were probably asking. was it multithreaded? mostly a big while loop? dunno
<kof13>
the usenix paper more or less covers that
<geist>
did it use protected mode, 32bit mode, mmu?
<kazinsal>
iirc the original netware server implementation was what we would today call an appliance
<kazinsal>
just a beige m68k box that booted straight into a custom server OS
<geist>
yeah didn't know that but makes sense
heat has joined #osdev
heat_ has quit [Ping timeout: 248 seconds]
<kof13>
that is how the paper describes the x86 stuff too. a network operating system, a file server, not general purpose/etc. later versions you could even use gcc to target though, and had bash and such IIRC
<kof13>
i mean, i like the software idea, just seems straightforward to me. pretend it is 1980 lol
<kof13>
no split between kernel and userland. no such thing as a "process" per se, just "threads" . this sounds like me lol
<kazinsal>
there's a book I have that's another good resource for old network OS stuff, lemme dig it out and find a link
<geist>
yah at somewhere they got ahold of the unix license and started making unixware, etc
<kazinsal>
the version I have has a different cover but it's the same book as far as I can tell
<kazinsal>
the picture on the hardcover option matches
<netbsduser`>
i had assumed before that netware was dead simple but based on what little i've been able to find it became considerably more sophisticated
<netbsduser`>
and cheers kazinsal that should be interesting
<kazinsal>
keep in mind it's mostly about 90s cisco gear
<kof13>
everything i have heard people say is it had its niche. and ...i think the main q is what else had multiplatform clients, and what was the cost, etc.
<kof13>
this is just to say, there was surely "non-technical" factors influencing people as well
<kof13>
that doesn't answer the question, just ...to take you back to 1990
<kof13>
vageuly related, later on (since the paper talks about "rpc" and i think a footnote said similar to corba, and mentions auto-generated "stubs/wrappers" similar to prototyping functions) ...next had their "distributed objects" stuff which people raved about...but what was the licensing cost at the time? <runs>
<kazinsal>
often Cisco will publish slide decks from Cisco Live a year or so after the convention they're from
<kof13>
*vaguely
<heat>
ChavGPT, why does linux think only reg and dir files need atomic seek?
<kazinsal>
fun fact: classic Cisco IOS and the IOSd process that runs IOS tasks on Linux are actually cooperative multitasking
<kazinsal>
with interrupts allowing for a virtual reschedule in case of a higher priority task coming into the queue
<ChavGPT>
heat: you do realize everyone gets atomic seek
<ChavGPT>
heat: except for the funky special case of the underlying file being sneakily duplicatd from under you by pidfd
<heat>
scratch that
<heat>
"All of the following functions shall be atomic with respect to each other in the effects specified in POSIX.1-2017 when they operate on regular files or symbolic links:"
<heat>
wait wdym?
cloudowind has joined #osdev
<heat>
only regular files and dirs get atomic seek
* cloudowind
greets everyone
<ChavGPT>
i thought you were talking abut the recent hack
<ChavGPT>
i'm guessing the rest is not seekable?
<ChavGPT>
modulo devices
<heat>
i'm looking at 6.5.2
<heat>
i guess
<heat>
POSIX only requires reg files
<heat>
and symlinks, but those are not seekable
<heat>
what will-it-scale did you use to test the single-threaded impact?
<ChavGPT>
read
<heat>
kk thx
<ChavGPT>
except if you bench linux you need to watch out for your kernel config
<ChavGPT>
there is massive pessimizations going in stemming from gcc being bad
<heat>
no im not benching linox
<zid>
Bloody wordle cheaters
<zid>
I messaged to my friend I had to guess a 1/6 to have gotten it in 3, so I felt very fortunate
<zid>
he replies that he got it in 3 too and showed me
<zid>
He hit a 1/102 chance.
<heat>
ChavGPT, mr mjg i need immediate URGENT HELP