<geist>
need to feed it more complicated things, and add code to actually configure it if it isn't already (assign bars, etc)
<geist>
but the basics is to get it into a tree like structure of objects so can manipulate it
<zid>
yea I don't store the tree, but that's neat
<zid>
I will probably eventually have a need to
<zid>
but for now I just broadcast the device/vendor IDs of things I find
<geist>
yah was debating but since i generally deal with ARM and RISCV most of the time, and qemu doesn't initialize those busses on bootup
<geist>
i'm going to pretty quickly need to add code to actually assign BARs and whatnot
<zid>
you'll need to write lspci at some point
<geist>
and for that it probably helsp to have a tree like structure so you can walk up and down the tree and compute the envelope of addresses, etc
<zid>
I really wanna get my shit to the point where I can write this webserver
<zid>
Then I can have lots of fun making display windows
<geist>
yah i'm just tyring to get this shit to the point where i can write some more PCI drivers, really
<zid>
like lspci.cgi.bin etc
<zid>
and a memory map viewer, etc
<geist>
like e1000, xhci. been meaning to do those so i know what i'm talking about
<zid>
dumping that stuff to the console is no good, you really want visualizations
<geist>
been mostly fiddling with non pci based things like virtio-mmu
<geist>
virtio-mmio that is
<geist>
which is fine for ARM and riscv, but doesn't work on x86 PC
<geist>
plus always kinda wanted to *actually* write an ahci or nvme or e1000 driver just to actually know what i'm talking about
<geist>
and those all work on non x86 too, so kills a bunch of birbs
<zid>
I have e1000 but it's pretty janko in terms of interface
<zid>
cus my network stack is still just a few if()s hardcoded against the e1000 :p
<geist>
noice
<geist>
yah mostly that with virtio-net on this end
<geist>
like stack is abstract fromthe nic, but only in that the virtio-net driver populates a send/receive function ptr and then stack goes to down
<geist>
funny how my old stac from 20 something years ago in newos was more robust there
<zid>
yea I don't have the ptrs
<zid>
mainly because I don't have a decent enough allocator to have things like.. linked lists or stacks
<geist>
oh get that going so you unblock yourself
<zid>
I've just been avoiding it rather than writing it
<moon-child>
I did a really shitty allocator in like a couple pages of code
<geist>
do it!
<zid>
who needs dynamtic allocations when you can use statics!
<geist>
yah i was actually using legit new a while ago
<geist>
i figure a machine with pci is probably big enough to handle some heap allocations
<geist>
it aint no embedded device
<moon-child>
linked list of variable-sized buffers, k&r style < linked list of blocks in 0.5k increments under 4k < freelist every 16-byte increment under 0.5k
<moon-child>
ezpz
<zid>
I just didn't wanna think about how to initialize it :p
<geist>
anyway, fun to just sit down and do some hackery on a concrete thing like parsing pci
<geist>
also managed to actually get into The Zone there for a couple hours
Oshawott has joined #osdev
<geist>
so far and few between these days. got some lo-fi girl going on the TV and just hack away
<geist>
she's still studying
archenoth has quit [Ping timeout: 250 seconds]
<kazinsal>
ever vigilant
<geist>
it's either lo-fi girl or Kid A
<j`ey>
geist: what machine is this?
<geist>
but Kid A is only like 45 minutes long
<geist>
j`ey: qemu, was piddling with trying to configure it with some pci bridges or whatnot
<j`ey>
arm? x86?
Burgundy has joined #osdev
<geist>
by default it tends to toss everyone on bus 0 which isn't that interesting
<geist>
j`ey: yes.
<j`ey>
hah
<geist>
i wrote bus accessors for 3 methods: bios32, classic PC x86 type 1, and ecam
<geist>
and obviously only the last one is supported on arm and riscv
<geist>
that's why i was piddling around with ACPI and device tree the other day, need to read the ECAM location out of those
EtherNet has quit [Quit: WeeChat 3.4-dev]
EtherNet has joined #osdev
<zid>
vmware's got a decent spread of shit on different busses
<klange>
geist: vmware sti-
<klange>
what zid said
<geist>
yeah should try that next
<kazinsal>
yeah, ESXi by default spits out an enormous number of bridges
<geist>
if you screw around you can more or less configure what you want on qemu but it's a pain
<geist>
you have to explicitly call otu root busses and whatnot and manually assign devices
<geist>
a lot of that depends on how much they follow the pcie spec. i think in general with pcie (Vs pci) you're supposed to create a bridge with a single device behind each one
<zid>
ah yes, it is
<kazinsal>
yeah
<geist>
but i think bus 0 is somewhat grandfathered in to having 'built in' devices
<geist>
including of course root port bridges themselves
<zid>
so device 1 on bus 0 is the PCI bus, device 11 on bus 0 is the pci-e 'stuff you added in config'
<geist>
if you dig around in something like the AMD BKDG you see that you can configure the 24 lanes of the SOC in a bunch of ways, and i thik the worst case scenario is something like 8 root ports of 4x lanes a piece
<geist>
so there's a root port slot reserved for each, though the bios probably configures it elsewhere, so those devices end up looking dark on a real machine
<kazinsal>
15AD:07A0 is the VMware PCIe root ports
<geist>
but then you can pretty much see how the south bridge chip will chew up a 4x lane, add their own bridge and then build secondary busses
<geist>
kinda neat that it basically lines up with reality
<kazinsal>
iirc the number of root ports it spawns is in the vmx, one sec
<geist>
iirc its ACPI also calls out something like 32 com ports, with 31 of them disabled. that caused some trouble with fuchsia at some point
<kazinsal>
I should look at the vmx file for a Windows VM to see if it does something different with the PCI config
<kazinsal>
wonder if VMware just makes up different "base configurations" for different expected guest OSes
<geist>
i wouldn't be surprised
<klange>
it does
<geist>
like it might not matter to linux, but probably matters to windows
<kazinsal>
oh yeah, those PCI slot numbers are way different
<klange>
you get different NICs between the "Other, 32-bit" and "Other, 64-bit" options
<geist>
one off the top of my head that i know is to this day windows still cares about socket vs cores on a socket
<geist>
like, come on seriously?
<kazinsal>
licensing thing, yeah
<geist>
i have a windows 10 qemu instance that i had to explicitly tweak for that. <eyes roll>
<kazinsal>
oracle DB cares about it too
<geist>
yah just figured that sort of thing is so 90s
<geist>
but alas.
<klange>
ooooh I see what happened, vmware you little shit...
<klange>
If you click in the guest without capture, it does something to make it not actually focus the window
<kazinsal>
should also be noted I'm working several versions of ESXi behind so I'd bet it does something different if you specify Server 2022 as the OS instead of "Server 2016 or newer"
<klange>
oh snap, I don't even need to click, it's just taking input for the guest whenever the cursor is over it, but not to its window in general, and then leaving it restores focus to whatever was focused previously
<klange>
and clicking the guest doesn't focus the vmware window (but clicking its menubar or decorations does)
<klange>
I'm still on X here, and I literally did wm/compositor stuff for ages, and I have no idea what they're doing here or _why_, but, ew
<geist>
one day i thought it might be interesting to actually try to grok precisely what goes on in a modern X + compositor + wm thing
<klange>
so between qemu, virtualbox, and vmware, they all do input _very_ differently
<geist>
like, which code does what
<geist>
but... i dunno
<klange>
demons
<klange>
demons and GLX_EXT_texture_from_pixmap
<geist>
i have a basic understanding of the old school X stuff, but how the compositor fits into it i dont know
<klange>
so there's the composite extension, which essentially has X itself stop rendering to the screen directly and lets a client application do it instead
gog has quit [Quit: byee]
<klange>
that extension takes care of the basic "render to a pixmap for each window" thing that is the fundamental operation of compositing vs. the traditional pen-and-primitives approach that X still supports
<klange>
and if you just want to do 2d stuff, that's fine and you can throw the results at, like, Cairo or your bitblitting.
gog has joined #osdev
rwxr has quit [Ping timeout: 260 seconds]
<geist>
hmmm, makes sense
<klange>
I have no idea what's state of the art and I last was into this stuff a decade ago, but the thing that allowed for OpenGL to come into the picture was GLX_EXT_texture_from_pixmap.
<geist>
figured it fakes out the app at that level
<klange>
So you can get a GL texture out of the pixmaps representing the windows and now you can put them on a cube.
<klange>
Though X is still managing the idea of where a window is and it only understands aligned rectangles
<gog>
mew
<klange>
So while we can put the windows, visually, on a cube, if you want to interact with them like they were on a cube... tough shit
<klange>
A bunch of hacks were tried back in the late oughties to get around that, but in the end no one cared enough and Wayland was right around the corner
mahmutov has quit [Ping timeout: 268 seconds]
<klange>
With Wayland, since it's just a protocol, you can do whatever the hell you want as a compositor because you're also the input manager. If you want to map windows onto walls in a virtual room and have the mouse by a VR lightsaber, you can do that because you decide where clicks go, or that a click is happening at all
<klange>
another important X extension was the damage extension
<klange>
the more common term for that is dirty rects, but "XDamage" was such a fundamental thing to Compiz not effectively sitting around constantly rendering the whole screen [or screens] at full resolution and 60fps and burning a whole in your GPU... that I still use the term "damage" when I talk about dirty rects.
<klange>
[though the term I use in yutani is just 'flip', which is... also kind of a minsomer, but it does the thing]
<geist>
makes sense
<klange>
thinking back to all the different ways we tried to cheat at input redirection in X...
<klange>
The most hilarious approach in retrospect was _to use VNC instead_.
<klange>
For Yutani, I support transformed input mapping, though just for rotation at the moment. It's my one neat parlor trick. Shame I don't have a good drawing app right now...
the_lanetly_052_ has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 260 seconds]
Oli has joined #osdev
qookie has joined #osdev
[itchyjunk] has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 268 seconds]
c2a1 has joined #osdev
ksp has joined #osdev
<ksp>
imagine not using IRC from some random OS made in Lisp
<ksp>
lol
<ksp>
it even has a doom fork
ksp has quit [Remote host closed the connection]
qookie has quit [Quit: leaving]
Vercas has quit [Quit: buh bye]
Vercas has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 264 seconds]
Vercas0 has joined #osdev
Vercas has quit [Ping timeout: 276 seconds]
Vercas0 is now known as Vercas
Qubasa has quit [Remote host closed the connection]
Oli has quit [Read error: Connection reset by peer]
Oli has joined #osdev
mimmy has joined #osdev
ElectronApps has quit [Remote host closed the connection]
c2a1 has joined #osdev
<froggey>
"some random OS" hrpmh
vdamewood has joined #osdev
vinleod has joined #osdev
mimmy has quit [Ping timeout: 240 seconds]
vdamewood has quit [Ping timeout: 264 seconds]
vinleod is now known as vdamewood
mimmy has joined #osdev
Kerum has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 265 seconds]
mimmy has quit [Ping timeout: 268 seconds]
_caveman has joined #osdev
dude12312414 has joined #osdev
mimmy has joined #osdev
_caveman has quit [Quit: WeeChat 2.8]
Kerum has quit [Quit: leaving]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
srjek_ has quit [Ping timeout: 264 seconds]
mimmy has quit [Ping timeout: 250 seconds]
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` is now known as X-Scale
mimmy has joined #osdev
mahmutov has joined #osdev
srjek_ has joined #osdev
srjek_ has quit [Ping timeout: 264 seconds]
srjek has joined #osdev
heat has joined #osdev
mimmy has quit [Ping timeout: 268 seconds]
<heat>
geist, you can also run EFI apps on EBC
<heat>
you just need a $900 compiler from intel to actually compile them
<zid>
EBC?
<heat>
also, SIZEOFS ARE FUCKING DYNAMIC CALLS
<heat>
zid, efi bytecode
<zid>
ah
<heat>
sizeof(UINTN) and sizeof(VOID *) can't be resolved at compile time, etc
<zid>
sizeof is an operator btw :P
<zid>
oh you mean in efi lang?
<heat>
so it's actually done dynamically
<heat>
what efi lang?
<zid>
EBC?
<zid>
cus in C it's definitely an operator
<heat>
efi bytecode is compiled from C using the aforementioned $900 intel compiler
<heat>
there's no special language
<heat>
structure sizes can also change
<heat>
god this is cursed
<heat>
thank fuck this is dead
<HeTo>
if sizeof isn't a constant expression, it's not C, but sounds like it's a C-like language
<zid>
sounds like.. completely normal program to me
<zid>
HeTo: VLAs made it non-constant
<zid>
not that the spec required the compiler to emit a constant load and optimize it all out etc in the first place
<heat>
i wonder if non-x86 UEFI firmware have the x86 emulator built in
<HeTo>
unless they push even more steps of the translation down to the part that you would normally call running the program
<HeTo>
zid: if the expression isn't a VLA, it can still be used in an integer constant expression
<zid>
okay?
<zid>
I was directly responding to something you said
<HeTo>
so, if you can't use sizeof (SomeStruct) somewhere where an integer constant expression is required, the language isn't C
<HeTo>
e.g. a case label
<heat>
HeTo, dunno how that works
<zid>
except, the compiler doesn't *have* to be able to resolve expressions to constants
<zid>
so again, that isn't true
<heat>
not that we have a way to test of course
<heat>
zid, cppreference says sizeof operators may be used in an integer constant expression
<heat>
when not VLA
<heat>
i assume this is in the standard as well
the_lanetly_052 has quit [Remote host closed the connection]
<zid>
can be used in
<zid>
the compiler does not have to be clever
<HeTo>
zid: the compiler has to permit you to use sizeof with a non-VLA type wherever the standard says a constant expression is required. it's true that the implementation can implement it however it wishes, but while you can't do case somefunc(): in C, you need to be able to do case sizeof (SomeStruct): for example, or make a global (so, non-VLA) array with size sizeof (SomeStruct)
<zid>
*exactly* that yes
<zid>
but not 'arbitrary express you believe to be constant'
<zid>
expression*
mimmy has joined #osdev
<heat>
ebc uses some really weird indexing
<heat>
it takes in constant units (bytes), then natural units (whatever is the machine's word size)
<bslsk05>
'Andreas Kling - Home' - 'Hello friends! I'm building SerenityOS, a new from-scratch graphical operating system for desktop computers.'
mimmy has quit [Ping timeout: 240 seconds]
<heat>
I think sizeof is implemented using the weird indexing they have
srjek|home has joined #osdev
srjek has quit [Ping timeout: 265 seconds]
CryptoDavid has joined #osdev
srjek|home has quit [Ping timeout: 260 seconds]
srjek has joined #osdev
mimmy has joined #osdev
mimmy has quit [Ping timeout: 250 seconds]
simpl_e has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
srjek has joined #osdev
archenoth has joined #osdev
Oshawott has quit [Ping timeout: 264 seconds]
dude12312414 has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
srjek has joined #osdev
mimmy has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
mimmy has quit [Ping timeout: 265 seconds]
[itchyjunk] has quit [Read error: Connection reset by peer]
<geist>
heat: yah that was my impression of it. I guess the whole C compiler for bytecode never made it into mainstream. Seems like LLVM/clang could deal with it nicely now, but the moment has probably passed and no one is going back and doing the work
<geist>
i suppose hypothetically with more ARM devices running UEFI it might be worth it, but IIRC you can also just provide multiple drivers (different arches) for devices in the rom image
<geist>
and the UEFI system just picks the right one. so not necessarily a need for a bytecode driver
srjek has quit [Ping timeout: 260 seconds]
mimmy has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
srjek has joined #osdev
rwb is now known as rb
mimmy has quit [Ping timeout: 268 seconds]
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 268 seconds]
GeDaMo has quit [Remote host closed the connection]
X-Scale` is now known as X-Scale
srjek|home has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
<heat>
geist, i saw a project in tianocore's wiki about porting llvm to EBC
<heat>
but they said multiple times that it's almost dead
<geist>
seems like that would be the only chance for survival
<geist>
yah
<heat>
it's not demanded by the spec anymore, it's optional
<geist>
one of those interesting ideas but the moment has passed
<geist>
and now things like embedding interpreters in large code bases is considered harmful
<heat>
they have a package in edk2-non-osi I think which is an x86 emulator, literally qemu tcg inside your fw
<heat>
that might be the way
<geist>
alas we're still stuck with the ACPI runtime that large things have to do
<geist>
but it came from that era of thinking at least
<heat>
I remember they also found a bunch of option ROMs which dereferenced the NULL pointer
<heat>
including an nvidia one lol
<heat>
that should totally break any ARM device I would guess
<heat>
since there's probably no ram at 0x0
elastic_dog has quit [Ping timeout: 240 seconds]
<geist>
depends. i'd say 50/50 but the general trend nowadays is to put peripherals at the bottom, then ram from then on out
<geist>
so yeah
<geist>
lots of times ROM is still at 0 though
<geist>
but yeah 0 as a valid physical address is a thing
<bslsk05>
www.lysator.liu.se: The Ten Commandments for C Programmers (Annotated Edition)
<kingoffrance>
ive kind of ...happy that's still a thing. not all things age so well
<kingoffrance>
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.
<heat>
NULL is also invalid in UEFI
<heat>
but mostly works since it's mapped and valid memory in x86
<geist>
yah in places where 0 is a valid physical address i usually just 'burn' that page
<geist>
ie, have the PMM returning page 0 being invalid and that's okay. that way you can still do a quickie assert that phys_addr != 0
<heat>
if your allocator returns struct page * you don't have that issue
<geist>
yah, but then you have a 'translate this to paddr', etc
<geist>
lots of cases where the paddr goes around, and if you can just arrange for 0 to be the invalid value you h ave an additional thing to assert against
<geist>
you can make the initial allocation api return an error or whatnot, which is generally a good idea (vs returning a pointer or whatnot) but down stream code many times translates to physiocal address and then deals with that (constructing new page tables, for example) so it's nice if deep in their code they can do something like ASSERT(paddr != 0);
<geist>
just one of those things i've found along the way
<heat>
kind of unrelated but have you tried out initialising the page allocator in parallel? in order to reduce boot times
<geist>
it is a thing i've thought about for sure
<geist>
at the moment it's the biggest pole in the tent for zircon boot
<geist>
since it explicitly constructs the pmm page structures at boot, so it scales with the number of pages
<heat>
I remember intel tried it out, they got to a point where they initialised X pages (so the system can boot comfortably) and then hotplug the rest
<geist>
i think linux has something like that now. makes a difference for really huge systems
<heat>
yup
<geist>
at the moment, for example, zircon kernel boots in something like 50ms on an intel nuc and like 30ms of that is initialzing the pmm
<geist>
on say a 16GB system
<geist>
the numbers are made up, but it's something like that. like 3/5 of the boot time is this one phase
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
it's kinda a tricky problem when you think about it. you could do somehting like just preinitialize a subset of pages you think are good enough to start the system booting, say up to 1GB of pages
<geist>
and then toss the rest in some sort of worker thread that runs post-SMP
<heat>
what happens if you touch the pages with no-caching hints? movnti or whatever that is
<geist>
so that you get some actual parallelism, vs some sort of false notion where a worker thread is just competing with system startup
<geist>
well, it's not the pages themselves, but the vm_page_ts which are these little structures
<heat>
yeah
<geist>
so you cant just slam zeros into them. they're actually intiailized to a particular value
<heat>
but won't touching every page in the system cause cache thrashing?
<geist>
what do you mean?
<heat>
when setting up the linked list of pages
<heat>
unless you don't do that but I think you do?
<geist>
possibly, though if you're walking through them in order you can kinda guarantee that the last page you're adding is linked to the one you just touched
<geist>
so you're walking through them in order
<geist>
since you're walking through them as an array (ideal) and then just chaining them together in a linked list in order it should be totally fine
<geist>
NUMA may be a thing, since hypothetically you want to construct a pmm node on a cpu that's within the same node
<geist>
but that's like a hard mode achievement
<geist>
all this side i haven't tried optimizing the page construction code, so it's possible there's some low hanging fruit in there that's easy to fix up
<geist>
possibly one of those C++ doing way too much stuff things that can be easily worked around
<geist>
i think we basically just placement new each page out of the pre-allocated array, so it's possible the constructor for the page does a lot more work than it strictly needs to
<geist>
especially since we have so many extra checks and whatnot enabled for the compiler that does a lot of extra work in a lot of cases
<geist>
basically the same code on LK, except in C so I should take a look there and see what's up
<j`ey>
Im guessing LK doesnt usually have 16GB of ram to init :P
<geist>
if you boot on a machine with that much, sure
[itchyjunk] has joined #osdev
<geist>
i think the max size is set by the amount of physmap that's allocated, which is per arch
<geist>
for zircon it's limited to 64GB for x86 and 512GB for arm64. basically arbitrary, and can bump it
mimmy has joined #osdev
<heat>
why so little for x86?
EtherNet has quit [Quit: WeeChat 3.4-dev]
<geist>
mostly because of the page tables. it can be bumped, but was expediant at the time
<j`ey>
64GB should be enough for anyone /s
<geist>
a) at the moment only use one top level page table in the PML4, thus the total kernel address space is 512GB
<geist>
this 64GB is a reasonable carve out for that
<geist>
b) at the time it didn't rely on 1GB pages existing, though i think that's not the case anymore. we basically decided screw it you need 1GB page support
<geist>
on arm64 the whole 'sharing 2nd level page tables with all aspaces' doesn't exist like it does on x86 and riscv so it's trivial to enable the full 48 bits of kernel space
mimmy has quit [Ping timeout: 260 seconds]
<geist>
and thus i use an entire 512GB 2nd level 'slot' for the physmap
<geist>
so in short still need to fix the problem to expand x86-64 kernel aspace out to 47 bits and use the whole space
<geist>
then can easily enable a huge physmap
<geist>
but it's just on the todo list
EtherNet has joined #osdev
<geist>
that reminds me, i once wrote a reasonably decent internal doc about zircon kernel memory management. always meant to publish that on the external site
<geist>
should do that once vacation is over then i can just point at it
<heat>
yesss
<geist>
i super suck at writing docs though, or more specifically i generally hate writing docs
<geist>
only every once in a while i suddenly get the urge
<heat>
la a0, %1; add a0, a0, tp; ld %0, a0 <-- does this look wrong?
<bslsk05>
www.kernel.org: Memory Layout on AArch64 Linux — The Linux Kernel documentation
<heat>
i'm getting a lot of undefined reference to a0
<geist>
heat: for what arch is that?
<heat>
riscv64
<geist>
okay good, right arch :)
<heat>
i forgot risc architectures are a bit too similar lol
<geist>
is this in inline asm? I assume so because of the %
<heat>
yeah
<heat>
it's a get_per_cpu() implementation
<geist>
i forgot if you needed % for registers or not. looking at my code
<heat>
godbolt says no
<geist>
oh i think it's the ld that is the problem
<heat>
how? it's a cross toolchain
<geist>
syntax for ld is `ld reg, (...)`
<heat>
AH LOL
<geist>
well more specifically `ld reg, N(reg)`
<heat>
N is an offset?
<geist>
er wait does it even have the N offset?
wikan has quit [Quit: Client closed]
<geist>
i always forget precisely how limited riscv is
<geist>
all i see in my code is (reg) so may be it doesn't do offset
<geist>
anyway, that's why
<geist>
what's interesting is why it didn't say it was a malformed instruction. maybe it was trying to construct a pseudoinstruction and then it was looking for the a0 label
<heat>
alright! no a0 undefined references now! thanks :)
<geist>
there are lots of pseudo instructions on riscv that are really worth having a read over and/or a page up and handy, since the assembler has pretty much full authority to do what it needs to do including replacing instructions with compressed forms, etc
<heat>
now I only have like 200 undefined references
<geist>
noice
<heat>
i need to stub everything out
<geist>
yay new port
<geist>
these are always fun
<geist>
anyway if you need help ask, but i'm going to avoid just pasting urls to my port so you can figure it out on your own :)
<heat>
never did one before
<heat>
ofc :)
<heat>
riscv seems easier but arm64 seems more useful
<geist>
yah riscv is pretty EZ mode
<heat>
since getting my hands on a riscv64 board is pretty expensive
<geist>
if anything simply because for a lot of the tricky tasks (how exceptions work, etc) there's so limited features available there's really only One Way to do things
<geist>
that took me some time to accept. I was hoping for more flexibility but nope. here it is. this is your exception, deal with it
<geist>
also things like delivering IPIs and whatnot. one way
<geist>
the hard part is like lots of arch manuals there's not an example chapter that says 'here's probably waht you want to do for X'
<sham1>
Well isn't the manual more like a reference and a spec than a programmer's manual as such
<geist>
it's like being given all the pieces for some lego set and no manual, but theres only like 20 pieces so you can kinda figure out how it fits together once you've examined all of them
<geist>
sham1: exactly
<heat>
intel gpu docs say "programmer's manual" iirc and they're mostly just a datasheet
<geist>
that's part of the fun of porting things to new arches. it's different lego sets with different types of pieces each of them, but you start to get a real feeling for how different types of lego like things work
<geist>
ie, duplos work kinda like legos kinda like capsellas, etc
<geist>
x86 is like a 10k lego set with 1/2 of the pieces not even being part of the final thing
<heat>
i like x86
<heat>
probably because it feels like home
<heat>
riscv and arm feels uncomfortable
<heat>
it's like learning a new programming language
<geist>
yah i get that. it's one of the reasons i like to work with other arches. i'm always into alternate ways to do the same thing. feels interesting
<geist>
i think it gives you some sort of perspective which can occasionally be useful
<bslsk05>
'Hand Drawing a RISC V CPU and Playing Bad Apple on It' by -T.K.- (00:05:41)
<geist>
i should look at that one more closely. i think i know that hardware simulator. what i dont get is the high rez display vs the low rez one
<geist>
the low rez one i get, that can basically just be a direct view of the register file, actually, and then you could write like a 5 instruction program that just reads it out of a memory bank
<bslsk05>
github.com: RISC-V-Single-Cycle-CPU/bad_apple.s at master · T-K-233/RISC-V-Single-Cycle-CPU · GitHub
<geist>
hah that's exactly what it's doing
<geist>
the huge grid on the right is basically 32 registers, notice the top left one is different? that's the zero register
<geist>
so basically it's walking through a data file, loading up 16 of the registesr it seems and then there's a set of latches to put them into some sort of i guess 16x16 display there
<geist>
ah yeah dumping it into what is pointed to by the gp register (at 0x4000)
<geist>
anyway, cute. the high rez vid must just be an overlay, not part of the simulation)
<heat>
yeah
<gog>
oh hey that's a tohou project thing
<gog>
my wife loves tohou project :p
<heat>
geist, it's hard to use builtins without libgcc/compiler-rt right?
<heat>
the linker was complaining about double-float vs soft-float so I took out libgcc plus crtbegin/end from the link and now I'm getting __bswapsi2, __ctzdi2, etc
<heat>
undefined references to them that is
<gog>
yep i played the video and as soon as the music started she looked over :p
DeepComa has joined #osdev
f4t4l_3rr0r has joined #osdev
f4t4l_3rr0r has quit [Excess Flood]
mimmy has joined #osdev
Arthuria has joined #osdev
DeepComa has quit [Ping timeout: 264 seconds]
mimmy has quit [Ping timeout: 256 seconds]
wootehfoot has joined #osdev
<geist>
heat: yes it is
<geist>
depends on the arch of course
<geist>
but since riscv doesn't have a lot of those fancy instructions it tends to lean on it more
<heat>
sucks
<heat>
i wish I could link libgcc but it's not compiled for soft-float