dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
Burgundy has quit [Ping timeout: 272 seconds]
eddof13 has joined #osdev
<vin>
Thanks moon-child Yes TLA+ is nice to represent a model I come up with but I am looking for analytical examples of expressing policies arithmetically
heat has quit [Remote host closed the connection]
immibis has quit [Remote host closed the connection]
immibis has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Jari-- has joined #osdev
<Clockface>
is there any way to tell GCC to use some of microsofts syntax instead when compiling?
archpc has joined #osdev
<zid>
masm syntax? no
<zid>
it can do intel and at&t
<Clockface>
for C/C++
<zid>
and by gcc I mean binutils
<zid>
by which I mean gnu as
<gog>
do you mean like __declspec ?
<Clockface>
i know there are some small differences between GCC and microsoft C stuff
<Clockface>
and i need to compile something in microsoft C world
<gog>
what extension does it need exactly?
<zid>
oh, msvc extensions
<clever>
zid: i see the news now, did you mean nvidia is open source, in the same way twitch is now open? lol
<Clockface>
it might not make any sense whatsoever and the decompiler is just outputting nonsense
<Clockface>
i am not very experienced in C
ElectronApps has joined #osdev
<gog>
ok first of all this is c++
<gog>
so if you're trying to compile it as c it's not gonna work
<gog>
second of all i can't begin to make heads or tails of this
<Clockface>
me neither
<Clockface>
also thank you
<clever>
zid: something else ive seen mentioned before, is that legally speaking, twitch isnt open source, and you can get into legal trouble if you are caught using that source
<clever>
zid: and that might explain the recent actions with nvidia, demanding that they open-source things, because then the source nvidia does release, is actually open
<clever>
but they are basically being black-mailed
eddof13 has joined #osdev
<gog>
whats with these goto's that have a literal is that even legal?
<klange>
Even "source available by intent of creator" isn't open source.
<klys>
the web gets fairly effectively censored these days, so no surprise if nvidia is not worried
<klange>
Please do not call leaks of any sort "open source".
<Mutabah>
gog: "computed goto"
<kingoffrance>
^ i think gcc supports it as an extension, or something "equivalent". yeah it very much looks like something a decompiler would output to mimic asm
sdfgsdfg has quit [Read error: Connection reset by peer]
sdfgsdfg has joined #osdev
<geist>
huh nice. sounds like fun. emulators are just fun to write
<zid>
gameboy is a nice peice of hardware to emulate too
<klys>
what's the gba cpu?
<zid>
gba is arm7tdmi
<zid>
gb is simple enough that most games will run in a couple of hours, but there's always more silly details to add that nothing actually cares about except the antagonistic test suites
<zid>
so you can just pick a random test and try to make it pass
<zid>
My favourite test: Setting the stack pointer to overlap the MMIO reg for the interrupt mask register, such that taking an IRQ causes it to push PC over it, disabling that IRQ, which causes the vector to come out as 0
<zid>
second favourite: The timer is completely broken in a number of obvious ways that cause it to tick spuriously
Terlisimo1 has quit [Quit: Connection reset by beer]
Terlisimo has joined #osdev
gildasio has quit [Ping timeout: 240 seconds]
gildasio has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
<Clockface>
how2build windows PE format with gnu binutils
<Clockface>
this is suprisingly annoying to find
<Clockface>
do they even build PE's?
<klange>
Yes.
<klange>
You just configure for a target that uses PE.
<zid>
ld blah.o -o blah.exe
<zid>
-mpei_386 or whatever the hell bfd backend PE uses if you've got a bunch of backends available
<klange>
pei-i387 or pei-x86-64 and I think for ld you'd want --oformat, not -m
<klange>
Also depending on the intended use, there are other approaches.
<klange>
For building EFI crap I build an ELF and then convert with `objcopy --target=efi-app-x86_64 ...`
<zid>
-m is the emulation at least
<klange>
that's a different thing, and the argument would be 'i386pep'
<zid>
'at least'
<zid>
as in, at least it was architecture related, even if it wasn't the right option
<Clockface>
is there a significant different between EFI or UEFI?
<klange>
Strictly speaking, EFI is the name of the original Intel implementation, and UEFI is the spec made by a corporate alliance after that.
<klange>
They are the same thing. EFI is one letter shorter, and a bunch of projects/tools/etc. were written before the U was introduced.
<zid>
I'm still yet to use uefi
<zid>
is there a uefi shell for qemu
<klange>
in so far as there is no specific implementation for qemu, no; the shell is just an EFI application, and I think most things have been throwing around the same tianocore version of it for over a decade ago
<klange>
s/ ago//
biosfood has joined #osdev
Matt|home has joined #osdev
biosfood has quit [Ping timeout: 256 seconds]
sonny21 has joined #osdev
sonny21 has left #osdev [#osdev]
sonny has quit [Ping timeout: 256 seconds]
FatAlbert has joined #osdev
FatAlbert is now known as attaboy
[_] has quit [Read error: Connection reset by peer]
eddof13 has joined #osdev
masoudd has joined #osdev
mrvn has joined #osdev
mlombard has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
sprock has quit [Quit: ...]
freakazoid12345 has quit [Ping timeout: 250 seconds]
sprock has joined #osdev
sprock has quit [Client Quit]
sprock has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sprock has quit [Remote host closed the connection]
sprock has joined #osdev
GeDaMo has joined #osdev
the_lanetly_052_ has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
_eryjus has quit [Read error: Connection reset by peer]
_eryjus has joined #osdev
bauen1 has joined #osdev
<attaboy>
what you guys use for production fzf or nerdree ?
<attaboy>
nerdtree
<zid>
not heard of either of them
<zid>
looks like vim plugins
<attaboy>
zid: yeah.. you use vscode i guess
<attaboy>
?
<attaboy>
i really wanted to try vscode but im afraid i don't have the time to learn new editor right now ( not that im a vim professional )
<zid>
no
<zid>
I just have never heard of some random specific plugins
<GeDaMo>
I'm not sure what 'production' means in this context
<attaboy>
im trying to find a "faster" way of working
<klange>
I use `git grep` for pretty much all of my code searching.
<bslsk05>
outerproduct.net: Why no one should use the AT&T syntax ever, for any reason, under any circumstances
<ddevault>
at least it's better than plan 9 flavored assembly
sdfgsdfg has quit [Read error: Connection reset by peer]
garrit has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dormito has joined #osdev
_eryjus has quit [Read error: Connection reset by peer]
_eryjus has joined #osdev
Burgundy has joined #osdev
dormito10 has joined #osdev
Clockface has quit [Ping timeout: 256 seconds]
dormito has quit [Ping timeout: 250 seconds]
dormito has joined #osdev
dennis95 has joined #osdev
dormito10 has quit [Ping timeout: 240 seconds]
Payam44 has joined #osdev
Jari-- has quit [Remote host closed the connection]
pretty_dumm_guy has joined #osdev
ravan has joined #osdev
blockhead has quit []
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
nyah has joined #osdev
<mrvn>
moon-child: That guy only ever learned x86 asm.
<mrvn>
Why do cpus even have 'mov eax, [edi + 8*ebx + 3]' and not 'mov eax, [edi + 8*(ebx + 3)]'?
<mrvn>
Except that it is real cool to use 1-tagged pointers and offset by -1.
<mrvn>
scratch that, works in both ways.
<mrvn>
The first case you only ever need for unaligned access, which is slow, never do that. Seems like a waste of bits to not shift the offset then because any sane code will have the lowest bist 0.
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
* mrvn
wants std::optiona::value_or_fn(callable)
<mrvn>
"It's just gonna work, don't worry about it." -- Arthur O'Dwyer
varad has joined #osdev
dude12312414 has joined #osdev
<varad>
o /
<varad>
I am writing x86 realmode->protmode transition code in gnu assembly
<varad>
I have the constraint that the protmode entrypoint address is stored in a register. How do I code this jump?
<mrvn>
so 16bit to 32bit?
<varad>
mrvn: yes
<mrvn>
don't. :)
<mrvn>
but since you do: what does the compiler say to "jmp %ax"?
dude12312414 has quit [Client Quit]
<varad>
that builds, but the jump target address fits in 32 bits
<varad>
the typical sequence would be: `ljmpl $CODESEG, $pm_entrypoint`, which works
<varad>
(pm_entrypoint is a 32bit addr)
<varad>
but I want something like `ljmpl $CODESEG, %ebx`, which assembler says is invalid
<mrvn>
iirc you need a far jump though, with a cs: and there are 2 options: put the stuff on the stack an far return or a db sequence for the hex of the opcode you actually want.
<mrvn>
If you have the address as register instead of symbol then I guess you want the stack way.
<varad>
I'm trying the far return way. I pushed $CODESEG and %ebx to stack, but lret after that takes the RIP into abyss
<GeDaMo>
I don't think there's a long jump which uses a register
<mrvn>
padding? alignment?
<varad>
I can't figure if I can jump to a 32bit address via `lret`
<mrvn>
why do you cli? if interrupts are enabled in 32bit mode then you are screwed, if you enable them before setting up all the irq stuff you are dead. Don't touch the irq flags.
<ddevault>
should already be disabled, added it again because voodoo
ElectronApps has quit [Remote host closed the connection]
<ddevault>
behavior does not change if it's missing
<mrvn>
and what is the reason given by the debug output?
<ddevault>
what I posted a moment ago is what qemu prints
srjek has joined #osdev
<ddevault>
no plain-english reason given
<ddevault>
but the behavior is a bit different
<ddevault>
lemme recenter the context, hold please
<bslsk05>
wiki.osdev.org: Setting Up Long Mode - OSDev Wiki
<ddevault>
as it appears now it boots up and fails to clear the display
<mrvn>
What's at 0x1000be?
<ddevault>
bits64
<mrvn>
but you are in 32bit mode
<ddevault>
bits64 is (supposed to be) the first line of code which runs in 64 bit mode
<ddevault>
did I miss a step in setting up long mode?
<mrvn>
aparently.
<ddevault>
hrm
<mrvn>
All the registers should be 64bit if you are in 64bit mode.
<mrvn>
CS looks right. Did you mess up the far jump to a new CS?
<ddevault>
I admit that I do not fully understand what needs to be set up with respect to segmentation here
<ddevault>
so the answer is I don't know
<mrvn>
Last I did this was 2016 or so. You have to check the manual or examples I'm afraid.
<ddevault>
I suspect that I have this set up correctly
<ddevault>
to state my assumptions:
<ddevault>
I believe CS needs to be 8 because the first non-null entry (i.e. at offset 8) in my GDT is the code segment
<mrvn>
Look at the example on the wiki, try if that works, then compare to see if you do the same things.
_eryjus has quit [Read error: Connection reset by peer]
<mrvn>
CS =0008 00000000 ffffffff 00af9a00 DPL=0 CS64 [-R-], notice the *CS64* in there. I don't know the bit pattern for 64bit code but CS64 sure sounds like qemu says it's 64bit code.
<mrvn>
So I think your CS is correct but you didn't switch to it right.
<ddevault>
hm
<mrvn>
paging is on, long mode is one?
<mrvn>
-e
_eryjus has joined #osdev
biosfood has joined #osdev
<ddevault>
well, I have made the same mistake as before of not using $, but corrected that to no avail
<ddevault>
if only it were that easy :(
<ddevault>
anyone got a tiny kernel handy which boots into long mode and does little else?
<ddevault>
ah, I have one right here actually
[itchyjunk] has joined #osdev
[_] has joined #osdev
[_] has quit [Remote host closed the connection]
<_eryjus>
ddevault: it may be more than what you are looking for but i recently chucked it all out and started over. This boots into long mode and outputs to the serial port, getting all the foundational bits (IDT, page mappings, higher kernel) along the way: https://github.com/eryjus/CenturyOS/tree/v0.0.0
<bslsk05>
github.com: GitHub - eryjus/CenturyOS at v0.0.0
<ddevault>
thanks _eryjus!
<mrvn>
_eryjus: damn, now I have no reason not to include that in the mini tutorial I'm doing for making a architectur independent kernel for arm/aarch64.
<_eryjus>
mrvn: happy to help
<_eryjus>
mrvn: if you want to wait, step 2 is intended to start the APs and boot them to a holding pen until the scheduler is ready.
<mrvn>
_eryjus: oh yeah, I need that and never done it before on x86.
<_eryjus>
i'll keep you posted
* geist
yawns
<geist>
good morning
<g1n>
hi geist
Brnocrist has quit [Ping timeout: 256 seconds]
Brnocrist has joined #osdev
h4zel has joined #osdev
philcox has joined #osdev
freakazoid12345 has joined #osdev
h4zel has quit [Quit: WeeChat 3.0.1]
h4zel has joined #osdev
dude12312414 has joined #osdev
biosfood has quit [Ping timeout: 272 seconds]
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
<mrvn>
is there some form of std::has_bigger and std::make_bigger for integer types? I want the next larger integer type for T, e.g. uint32_t -> uint64_t, uint64_t -> fail
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
mahmutov has joined #osdev
<geist>
hmm, good question. maybe that's part of the type traits stuff?
<mrvn>
I'm just watching an 1h talk about (a+b)/2. Writing that is horrible and assumes 2's complement on top. Can't fix the last one without making the code worse. But for all but the biggest integer type just do (a+b)/2 with a bigger type, right?
<bslsk05>
'CppCon 2019: Marshall Clow “std::midpoint? How Hard Could it Be?”' by CppCon (01:02:32)
heat has joined #osdev
<mrvn>
urgs. what type is ptrdiff_t? It has to be big enough to hold the difference between any 2 pointers. So a=0x8000_0000_0000_0000 and b=0x7FFF_FFFF_FFFF_FFFF. What's a-b and b-a? Will ptrdiff_t be 128bit or does the compiler assume a user/kernel split and only deals with user pointers? *test*
toulene_ has joined #osdev
<mrvn>
Celebrate International Women’s Day
<mrvn>
9+
<mrvn>
DE
<mrvn>
.oO(No, I did not want to paste Add garbage. Thank you firefox)
<mrvn>
sizeof(ptrdiff_t) == 8.
toulene_ has quit [Remote host closed the connection]
<geist>
yah ptrdiff_t is i think always the size of a pointer. basically a signed uintptr_t
<mrvn>
a-b = 1, b-a = -1
Arsen has quit [Quit: Quit.]
<geist>
and if you add it to the base you get the other back
<mrvn>
But the answere is 2^64 - 1
philcox has left #osdev [#osdev]
<geist>
(except that signed doesn't wrap)
<geist>
but if you ignored that it does work even for 2^64
Arsen has joined #osdev
<geist>
but anywa that's how it is, i didn't make the rules
<mrvn>
Fails on amd64 because it walks through the memory hole in the address space at 0x8000'0000'0000'0000
<geist>
64 is less interesting, in a 32bit machine it really exists already, especially ifyou have say an 3GB user space
<geist>
since you can legitimately have a diff greater than one half of the signed space
<geist>
i suspect you're supposed to treat it like an opaque thing, and not actually interpret it maybe
<geist>
supposed to be used for indexing into arrays and whatnot, and if the result is > PTRDIFF_MAX it's undefined, etc
<geist>
has all the usual caveats: may only be used to compare the diff between pointers in teh same array, etc
<mrvn>
and PTRDIFF_MAX is 1LLU<<63
<geist>
so that does tend to imply that on a 32bit machnie you cannot have an array > 2GB
<geist>
which is a Real Thing
<mrvn>
So I can't have an array that is more than half of 64bit address.
<geist>
for 64 its pretty academic because no hardware lets you do it, but 32 it's real
<mrvn>
I tried to construct a case for amd64 where it fails but the memory hold in the middle means an array is always smaller than PTRDIFF_MAX. Have to go to 32bit...
<mrvn>
PTRDIFF_MAX on x86 is 1LLU<<31. :(
<mrvn>
geist: from the talk "a single array? It would be a weared case". But hey, every sorting benchmark for char arrays will run into this on x86, right? Sort 3 billion chars....
* geist
nods
<mrvn>
Could be relevant for kernels. Have to be really carefull when doing range checks and length calulcation on syscall arguments.
<geist>
huh, interesting. the newest ARM ARM includes ARMv9. i was expecting there to be a separate ARMv9-A doc (vs v8)
<geist>
but it guess its so close they decided to just add more compelxity to the already complex v8 doc
<geist>
and *also* describe v9 with it
<mrvn>
That's the one I'm reading. It's horrible.
<geist>
ah it at least formalizes what i generally knew: armv9.0 == armv8.5+, v9.1 = 8.6, etc
<bslsk05>
github.com: STL/numeric at main · microsoft/STL · GitHub
<Bitweasil>
(or AArch32 for EL0 only)
<clever>
Bitweasil: but if you have a 32bit EL0 under a 64bit EL1, how does the paging tables work?
<Bitweasil>
I'm totally fine with it.
<clever>
is it just limited to the lower 4gig of the 64bit tables?
<mrvn>
clever: the MMU walks the 64bit page tables
<Bitweasil>
How would you like them to work? Mostly, you use AArch64 tables to translate the first 4GB virtual, yes.
<clever>
ah
<clever>
so yeah, you can ditch support for the 32bit tables
<Bitweasil>
Page tables are controlled by EL1, EL0 doesn't know or care how VA->PA translation happens.
<clever>
and also the LPAE stuff
<Bitweasil>
It could be by Amazon Turk for all it knows.
<clever>
yeah
<j`ey>
Amazon TurkLB
<Bitweasil>
Yeah, the 32-bit tables, once you start supporting virtualization and such, get gnarly.
<mrvn>
So you are basically just loosing the 16k/1k page table mix. YOu still have 4k, 16k pages, 2M, 1G pages, ....
<Bitweasil>
Worse, ARMv8 supports different page granule sizes, so 4kb, 16kb, 64kb pages, with the page tables and large pages that go with that.
<Bitweasil>
But it's more straightforward.
<mrvn>
Bitweasil: or not. all sizes are optional.
<Bitweasil>
That too, of course.
<Bitweasil>
(I don't get to opt out of many "optional" bits in what I'm writing, sadly)
<j`ey>
mrvn: not all sizes :P
<mrvn>
that part scares me. One day I will buy a new SOC, e.g. M2 maybe, and my kernel won't boot because no 4k pages.
<Bitweasil>
(though my GICv2 is missing the NSACR stuff in the distributor)
<j`ey>
(in that at least 1 should be supported on a CPU :))
<Bitweasil>
I would be *very* surprised if 4k pages go away.
<Bitweasil>
Since that's been part of computing for so long.
xenos1984 has quit [Read error: Connection reset by peer]
<Bitweasil>
I think Apple uses 16kb pages on iOS?
<mrvn>
j`ey: is it? My CPU has no mmu so all feature bits for pages sizes are 0. :)
<Bitweasil>
Haven't checked on the M1.
<j`ey>
16K for macOS on M1
<mrvn>
Bitweasil: I think geist mentioned that and suggested that maybe M2 could drop 4k pages since they don't use it.
<mrvn>
as in "If anyone would do that then they would"
<geist>
yah. my guess is they use 4K pages as long as they have x86 emulation
<clever>
geist: you said something before, about the arm recommendation being that each peripheral have a fairly wide spacing?
<geist>
yah re: EL1+ arm32 removal, i asked an ARM engineer once about that and they said it'd reduce their complexity a lot
<clever>
so even with 16k or 1mb pages, you can still mmu off a single peripheral
<geist>
there's tons of hard coded logic in there to handle the arm32 system state, exception nmodel, etc
<clever>
i forget the exact number you said though
<geist>
64k
<mrvn>
clever: it's in the specs, saw that too.
<geist>
i think you're supposed to separate MMIO apertures by 64k
<mrvn>
largest supported small pagesize
<geist>
right
<clever>
and the rpi is violating that recommendation, every peripheral is in a 4k slot
<geist>
yep. yes it is
<mrvn>
clever: does RPi support 16k/64k pages?
<geist>
so for example, if we switched fuchsia to 16k page granule, then we'd hvae problems with user space drivers getting just the mmio aperture they're assigned to
<geist>
sinc eyou have to map the stuff around it
<j`ey>
mrvn: 64k, not 16k
<clever>
mrvn: from what i remember of the arm32 docs, 16k/64k/1m pages, are all implemented by just filling multiple slots in with the same base addr, and setting a size flag
<geist>
Bitweasil: re M1 it appear to support 4k and 16k only
<clever>
so its kind of backwards compatible
<mjg>
huh?
<mrvn>
clever: that's arm32 with 4k/16k pages. I'm talking aarch64.
<clever>
and the only thing the page-size controls, is how big the TLB slot covers
<mjg>
that's pretty weird re lack of 1MB or biggerpages
<clever>
ah, ive not reviewed the aarch64 docs as closely
<geist>
mjg: sorry, meant base page granules
<geist>
the larger pages are of course supported because they're mandatory
<geist>
as in given a particular base granule size, you are required to support a medly of contiguous and block pages
<mrvn>
clever: The specs say, iirc, that the peripherals should be separated by the supported page size so each can be mapped. If you only support 4k then 4k separation is fine.
<geist>
where L0 - L3 is root down, and the 'contig' pages are the intermediate sizes where you combine multiple contiguous PTEs
<j`ey>
mrvn: yeah but rpi4 supports 64k!
<mjg>
hehe, now i'm surprised the other way
<Bitweasil>
clever, the Rpi violates an awful lot of recommendations. :p
<mjg>
up to 4TB (not taht i expect any real chip to have it)
<Bitweasil>
I'll glare at the Pi2/Pi3 interrupt controller.
<Bitweasil>
Intern level work, there!
<mrvn>
j`ey: wow.
<Bitweasil>
"What is the utter minimum we can do to bolt a multi-core interrupt controller on? Yeah, that'll do!"
<clever>
Bitweasil: even the GIC stuff is a mess
<Bitweasil>
Only the 4 has GIC, correct?
<clever>
Bitweasil: every PL011 uart, is routed to a single interrupt pin on the pi4's GIC
<Bitweasil>
oh ffs.
<Bitweasil>
I'm not surprised, either.
<Bitweasil>
(I'm currently writing a GICv1/GICv2)
<geist>
mjg: yeah there's ome verbiage in the ARM ARM about how it's okay for an implementatio to support particular larger pages via smaller TLB entries
<mrvn>
clever: what else should they do? Redesign the VC to export multiple interrupt lines?
<geist>
so you have to consult the per core manual to see what raw TLB entry sizes it supports
<clever>
mrvn: the previous iteration only had a single PL011 uart
<geist>
but usually it gets the basics: 4k, 64k, 2MB (if a 4/64 implementation) and adds 16k if it aso supports that
<clever>
mrvn: so they where already modifying it to add multiple uart's ontop of things
<geist>
the 512MB, 1GB, and 4TB pages are *probably* not implemented directly on any implementation
vdamewood has joined #osdev
<geist>
but the ARM ARM says TLB flushing of those must be transparent
<clever>
Bitweasil: its also my understanding, that there is zero way to do irq routing on any model, only the IPI's and per-core timers can target different cores
<clever>
Bitweasil: all interrupts from outside the arm, must go to a single core
<Bitweasil>
On the 3 and prior, yes, that's correct. I don't know about the 4.
<Bitweasil>
But with the 2, for sure, you can only ever send hardware interrupts to one core. Pick which one.
<clever>
the 4 appears to do the same, even with the gic
<Bitweasil>
Not surprising.
<Bitweasil>
Have you seen the Rock5 announcement? I've got a few on preorder...
<geist>
clever: not so sure there, i thought they bolted the GIC on underneath the legacy controller?
<Bitweasil>
They look legitimately good, at least on paper.
<geist>
or is it wired up in parallel?
<mrvn>
geist: If you do 4k, 2M, 1G, 16k, 32M, 64G, 64k, 256M, 1TB, ... seriously at what point do you just throw out the old TLB and design one that works with arbitrary addr, mask pairs?
<geist>
GICv2 definitely supports redireting SPIs
<Bitweasil>
I've not looked at the Pi4 from that level.
<clever>
root@pi400:~# cat /proc/interrupts
vinleod has joined #osdev
<geist>
mrvn: implementation detail
<geist>
but it doesn't support *that* many
<Bitweasil>
GICv2 does, the Pi... can be special.
<clever>
geist: checking this file on a pi400, i can see that nearly every irq is going to core-0
<clever>
the only exception is the IPI's and the arch_timer
<Bitweasil>
Same is true on mine, but I don't know if that's a hardware limit, or a "Eh, it works well enough..." configuration.
<geist>
only 4k, 16k, 64k, 2MB, 32MB, 512MB, 1GB, 4TB(*optional)
<mrvn>
geist: sure. But surely with even 5 or 6 page sizes the generic solution becomes easier in silicon and then you get all page size for free in the TLB.
<Bitweasil>
I'm not sure about that.
<clever>
Bitweasil: the genet controller can irq so hard that core-0 becomes starved for clock cycles and your network performance dips
<Bitweasil>
Search complexity goesup then.
dennis95 has quit [Quit: Leaving]
<geist>
indeed, which is also why the ARM ARM says the core may implement less TLB sizes in hardware as log as it appears to
<Bitweasil>
clever, yeah, I know. The Pis are an abomination, but they're well supported and at least used to be available...
<mrvn>
then you pay for the missing sizes with more flushing logic
<Bitweasil>
I'm planning to sell my 8GB Pi4, they're going for almost $200 used.
<geist>
so i think most implementations get 3 or 4 of those sizes, and also why lots of older implementations dont implement 16K base granules since that amost certainly requires more native TLB sizes
<geist>
vs 4/64k which nicely aligned up with base sizes it already needed to support (since 4k pages also allow for 64k contig pages)
<clever>
Bitweasil: ive also seen directions online, of how to transplant the ram from a pi4 to a pi400, to make a pi400-8gig
<Bitweasil>
Rock5: SoC – Rockchip RK3588 octa-core processor with four Cortex-A76 cores @ 2.4 GHz, four Cortex-A55 cores @ 1.8 GHz, an Arm Mali G610MC4 GPU, a 6TOPS NPU, 8K 10-bit decoder, 8K encoder
<Bitweasil>
System Memory – 4GB, 8GB, or 16GB LPDDR4x
<geist>
basically adding 16k base adds about half of the total page sies to the list
<Bitweasil>
Plus NVMe.
<mrvn>
hehe, I really like the way 16k pages in ARMv6 is done. You have to put in 4x4k pages and then the TLB can work either way.
<bslsk05>
www.tomshardware.com: Raspberry Pi 400 Gets 8GB of RAM in DIY Hack | Tom's Hardware
<Bitweasil>
mrvn, yeah, "hideous hack. :p
<geist>
that's how contig pages work in armv8
vdamewood has quit [Ping timeout: 240 seconds]
<Bitweasil>
Huh, I don't think I realized the 400 was 4GB only.
<mrvn>
is that 64k contig. case the same hack as 16k contig was?
<geist>
there's some complexity there: you have to put like 8 page table entries in a row, mark them as contig, and it's up to SW to make sure they are the same value
<geist>
yes
<clever>
Bitweasil: also, the pci-e/xhci interrupts are all MSI, so there is no limit on how many irq's you have, but linux only sets up a single irq to core-0
<geist>
'contig' pages in my table is literally what happens when you do this. it gets you to intermediate page sizes that arent 'block' pages
<geist>
the complexity is that if the cpu supports A and D bit writeback, it can writeback to *any* of those entries
<Bitweasil>
ARMv8A still only has IRQ and FIQ pins...
<geist>
probably based on how it faulted, or how the hardware is implemented (true native size or not)
<mrvn>
do you flash the contig pages 8 times or do you check a feature bit and then only have to flush once?
<geist>
TLB flush? flush once i *think*
<geist>
been a whiel since i looked at it. still haven't added support for it on zircon
<geist>
the feature is always there at least, so you dont have to check a feature bit
<mrvn>
wait, was 64k contig required if you do 4k?
<geist>
yes.
<Bitweasil>
Been a while since I worked on ARMv7 MMUs too...
<mrvn>
oh, ok. so the TLB has to flush that correctly then.
<geist>
that's why i was saying if hardware supports 4K granules it has to support 64k contig pages whcih means 64k granules are probably 'free' since you need TLB support for it
<mrvn>
Iirc correctly with 16k pages if the core doesn't support 16k you have to flush each 4k page yourself.
<geist>
armv8?
<mrvn>
(32bit)
xenos1984 has joined #osdev
<geist>
oh armv6 dunno. mostly purged that from my memory
<clever>
i have mmu code that works on v6 and v7
<geist>
side note, there's a AMD feature that supports more or less the same contig thing
<bslsk05>
github.com: rpi-open-firmware/mmu.c at master · librerpi/rpi-open-firmware · GitHub
<geist>
but it's transparent, apparently
<mrvn>
You could 16k contig pages nearly transparently on RPi except for that flushing bit because the cpu doesn't actually do 16k pages.
<clever>
i believe its using 1mb pages
<clever>
so i only need a single level to the paging tables
<geist>
yeah you can do contig pages without hardware support on x86 or anything else if you want, that's just SW emulating larger pages
<clever>
which greatly simplifies the init, .bss just contains a single level, and no need to compute how much the 2nd level fans out
vinleod is now known as vdamewood
<mrvn>
clever: it's nice until you want to map 4k peripherals somewhere.
<clever>
mrvn: i just identity map everything, the only purpose of this setup is to make the d-cache work
<clever>
and its getting town down within 30 seconds, when i pass control on to linux
<clever>
since its only a bootloader
<geist>
yah
<geist>
usually for just getting things working i just map the 1GB page around the mmio peripherals or whatnot
<geist>
but depends on the layout of periphs
<mrvn>
I considered doing it for the kernel boot.S. But then the kernel has to emidiately go and replace the page table with a 4k flavour one which is ugly at that stage.
<bslsk05>
github.com: lk-overlay/stage1.c at master · librerpi/lk-overlay · GitHub
<clever>
yeah, that .bin stage is not PIC
<clever>
but its also responsible for bringing the dram controller online
<clever>
and can only ever be loaded at 0x8000_0000, by the maskrom
<mrvn>
hence: elf loser in C -> gcc -S -> check and fix non-PIC -> assemble.
<mrvn>
loader
<mrvn>
As said I have a different target: Compile once, run everywhere.
<clever>
yeah, very different goal
<mrvn>
But so far the rewrite is working out nicely.
<clever>
linux reaches that goal, by having a hand written boot.S stage to bring the mmu online, but yeah, you then need to either move things or pad
<clever>
i can kinda see the zImage compression stuff helping there
<clever>
pad it to crap, then compress, and it wont be an issue
<mrvn>
totally.
<mrvn>
But make the compressor decompress to a aligned address or you are screwed.
<clever>
yeah
heat has quit [Remote host closed the connection]
<mrvn>
or just compose the decomress and elf loader and have it decompress into higher half where the blocks need to end up.
<mrvn>
Let's make an ELFz standard where segments can be compressed. :)
<clever>
the official rpi firmware, also does relocation in a totally weird way
<clever>
relocation is not metadata in the .elf
<clever>
relocation is a binary patch, applied to the entire .elf blob, headers and all
<clever>
so it mutates the DT_LOAD commands in the elf headers, to make it target somewhere else
<clever>
and mutates all absolute addressing within the .text/.data
<mrvn>
kind of what geist does. ELF reloactions are hard so lets extract that info at build time into a simple array and have the boot.S relocate us.
<clever>
before RPF had done that, they instead just linked the firmware ~4 times
<clever>
and supplied the end-user with 4 variants, for different sizes of gpu_mem and different rpi ram sizes
<mrvn>
Has anyone tried to send pull requests to github.com/microsoft/STL (or similar) to get some code fixed or improved?
<bslsk05>
microsoft/STL - MSVC's implementation of the C++ Standard Library. (1074 forks/7561 stargazers/NOASSERTION)
<mrvn>
how "open source" are they?
<Griwes>
depends on which definition of that phrase you use
<Griwes>
they have a cla in place, and the license is apache with llvm exception
<Griwes>
they take contributions in a reasonable way last I heard
<Griwes>
ymmv but from my point of view they are more open source than libstdc++ (which I am not allowed to look at)
<j`ey>
how is libstdc++ not open sourc
<j`ey>
?
<j`ey>
or do you just mean hard to contribute to?
<mrvn>
j`ey: they only accepts patches from people that work for GNU
<mrvn>
for copyright reasons
<Griwes>
it's hard to contribute to libstdc++
<Griwes>
but I am also not allowed to look at
<Griwes>
because one of the things I work on is a non-gpl implementation of the standard library
<Griwes>
so it may as well be proprietary license for me
<mrvn>
you can look all day. But you can't copy&paste or closely reimplement.
<j`ey>
right, but I wouldnt relate that to open source heh
<mrvn>
Which is basically impossible. So don't look and nobody can say you copied.
<Griwes>
there's more than legalese involved, there's also company policies that go beyond the explicit legalese to be especially safe about things
<Griwes>
j`ey, hence ymmv
<mrvn>
But to be honest isn't your non-gpl product to blame? :)
<Griwes>
no :P
<Griwes>
my product is also apache with llvm exception
<Griwes>
it's also open source
<j`ey>
libc++? or?
<Griwes>
derivative of it
<mrvn>
You still can't just blame one side.
<Griwes>
sure can
<mrvn>
well, can't stop you. :)
<mrvn>
s/can/should/
<Griwes>
that's a fairer statement, though I'll still disagree ;>
<mrvn>
to paraphrase: licenses are like assholes, everybody has one.
<mrvn>
it's mostly just taste and you can argube about taste for days and days.
<Griwes>
yeah
<Griwes>
I know that this crowd is fairly pro-gpl which is why I'm leaving this as "sure can blame just one side" and refusing to elaborate :P
<mrvn>
One thing I have to say is that the GPL and it's viral property had it's place in the past and we wouldn't have the open source environment we have today without it.
<Griwes>
I agree with *that*, yes
<mrvn>
My hope is that in a few decades people will say the same about software patents.
<mrvn>
Imho software patents are just a sneaky way to get around the open source licensing of your code. It's open and free and hurray. But if you use it we will sue you into the ground.
<mrvn>
(well, not just but in combination with an open license)
<Griwes>
I think we need to wait for a couple more generations to retire before we can fix some of these mindsets
<mrvn>
nod
<mrvn>
hopefully the same will happen to hardware specs.
gildasio has quit [Remote host closed the connection]
Teukka has quit [Quit: Not to know is bad; not to wish to know is worse. -- African Proverb]
<geist>
apple is currenlty announcing their new cpu and whatnot
<j`ey>
M1 Ultra
gildasio has joined #osdev
<geist>
ULTRA
<Griwes>
I think they are trying to one-up our "super" branding lol
Teukka has joined #osdev
<geist>
if they make a bigger one, will hey call it M1 EXTREME?
<geist>
i'd make the PLAID joke, but now tesla's gone and ruined that forever
sprocket has joined #osdev
<GeDaMo>
Super-hyper-mega M1! :P
<mjg>
looks inspired by graphic card naming, back in the day at least
<mjg>
wait for exclamation points as an integral part of the name
<bslsk05>
www.cnx-software.com: ROCK5 Model B RK3588 single board computer is up for pre-order for $79 and up - CNX Software
<Bitweasil>
four Cortex-A76 cores @ 2.4 GHz, four Cortex-A55 cores @ 1.8 GHz, an Arm Mali G610MC4 GPU
<j`ey>
very nice
<Bitweasil>
And a micro-HDMI *input*
<Bitweasil>
So you might be able to use it as a "KVM for other machines" sort of thing with a bit of fiddling.
Payam3 has joined #osdev
<Bitweasil>
2x HDMI 2.1 up to 8Kp60
<Bitweasil>
1x USB-C via DisplayPort alt. mode up to 8Kp30
<Bitweasil>
(outputs)
<clever>
Bitweasil: my nas motherboard has hdmi-a input, and the docs claim it can act as an hdmi passthru, but i see zero way to activate it
<Bitweasil>
> Based on th early RK3588 benchmarks we’ve found, Rockchip RK3588 should be over twice as fast as Amlogic S922X as found in ODROID-N2+ for many tasks, and the GPU performance increase should even be more impressive.
<Bitweasil>
I've got some N2+s, and I quite like them, but they're seriously RAM choked on 4GB.
<CoffeeMuffin>
The only problem with Apples computers is that they run MacOS.
<j`ey>
Bitweasil: let us know how it goes
heat has joined #osdev
<j`ey>
CoffeeMuffin: the m1 machines run linux too ;)
<CoffeeMuffin>
do they run with offical support?
<j`ey>
no
<Bitweasil>
Apparently quite well, I've debated trying that on mine.
<Bitweasil>
Apple neither helps nor hinders the process.
<mrvn>
Bitweasil: does that rock5 have 2 M2 slots?
<Bitweasil>
But they keep a "You want to boot your own kernel, here's how you do it" mode available.
<Bitweasil>
mrvn, one NVMe slot on the back, one wifi slot on the top.
<Bitweasil>
... so, yes, I think so.
<CoffeeMuffin>
most FOSS drivers are not as good as the original ones
<heat>
Bitweasil, they do hinder you by not giving you docs
<mrvn>
Bitweasil: ahh, they look the same, right.
<Bitweasil>
That's just "not helping."
<Bitweasil>
Hindering would be "You can only sign Apple signed OS images and there's no workaround."
<Bitweasil>
They are not going out of their way to make it easy, neither are they going out of their way to make it hard.
<CoffeeMuffin>
they had some machines where they had those "security chips"
<Bitweasil>
Sure, the T2.
<Bitweasil>
But there's a way to, through official means, "turn them off" in terms of boot security.
<Bitweasil>
The M1 has similar protections, locked down by default, but you can drop into recovery and turn that sort of stuff off, if you want to.
<Bitweasil>
Very similar to Chromebooks, IMO - secure by default out of the box, but "your hardware, if you want to hack on it, here's how you do it."
<heat>
do you still keep the warranty?
<Bitweasil>
I've never heard of it being a consideration... not like you're able to overclock it or something.
<heat>
in most android phones if you unlock the bootloader (essentially the same thing) you lose your warranty
<CoffeeMuffin>
the joke is that Apple is known for weaseling out of warranty with all means possible.
<heat>
s/Apple is/vendors are/
<Bitweasil>
^^
<Bitweasil>
I didn't realize you lost warranty with Android unlocking. I've only ever really hacked with Nexus devices.
<Bitweasil>
And I don't think you bothered warranty with that.
<heat>
i think google is noticeably better when it comes to those things
<mrvn>
heat: if you boot your own kernel and it burns out the TFT screen it's not really apples fault.
<heat>
if the screen can be burnt out that easily, it is apple's fault
<heat>
not your fault that the hardware is crap
<heat>
what happens if the official kernel has a bug(because things have bugs) and fucks up the hardware?
<mrvn>
heat: it's trivially simple to burn out the TFT or dram or cpu if you configure it wrong.
<Bitweasil>
"Sucks to be you, you know, the new version is 1.2x faster, you really should get it, plus more Gs for the network!"
<mrvn>
heat: if the officisal kernel does it then apple is at fault.-
<Bitweasil>
"Yeah, we tried to release an update, but by the time the carriers denied it, the damage was done..."
<Bitweasil>
I'm seriously considering a landline again.
<heat>
hardware should be resistant to bad values/programming
<heat>
like most hardware is
<mrvn>
most hardware is software nowadays
<j`ey>
Bitweasil: long cable :P
<Bitweasil>
Should be, yes. Generally isn't even robust to aggressive access anymore.
<Bitweasil>
j`ey, I think there's copper running down our driveway they could extend over to the house.
<Bitweasil>
House doesn't have internal wiring for it, though. :/
<Bitweasil>
I should have asked for the option when we got it made.
<j`ey>
you made your house?
<Bitweasil>
When we ordered it.
<j`ey>
very cool
<Bitweasil>
[insert whatever the heck other people call the process of producing and installing a manufactured home]
h4zel has joined #osdev
GeDaMo has quit [Remote host closed the connection]
<Bitweasil>
I got a bunch of other upgrades, 20A circuits, 12AWG wire, plumbing for gas (even though we don't have NG or propane here, it was insanely cheap to add it if we want it later), etc.
<Bitweasil>
Metal roof. Quartz counters.
<heat>
manufactured homes aren't really a thing in europe
<Bitweasil>
It's quite configurable, we moved a few interior walls around from the plan too for a bigger shower.
<Bitweasil>
They're not really a thing in most of the US either.
<Bitweasil>
"eeeewwww, a *trailer home*!"
<Bitweasil>
But they're common enough in rural areas, and there are some properly nice triplewides out there...
<Bitweasil>
They stand out once you know what to look for.
<Bitweasil>
And we quite like ours.
<heat>
ah I was thinking about prefabs
<Bitweasil>
I'm not sure the difference you're thinking of.
<j`ey>
trailer = on wheels
<Bitweasil>
The difference between "manufactured" and "modular," at least in the US, is mostly "Do the wheels stay under it?"
<Bitweasil>
Ours came in on wheels, we've got a concrete foundation, the axles are still under there.
<Bitweasil>
Or at least the springs.
<Bitweasil>
I think they take the axles back.
<Bitweasil>
If it comes off the trailer and doesn't have those bits, it's modular.
<Bitweasil>
And there are some minor legal differences, but they literally come out the same factory.
<Bitweasil>
We have separate property tax bills for the house and the ground, because I didn't do the paperwork to make ours "real property." Only difference, since we don't ever plan to move, is slightly higher valuation for taxes.
<Bitweasil>
(not that I think it would make a bit of difference if we did sell)
<Bitweasil>
But we've got a perfectly nice 2k sq ft doublewide.
<Bitweasil>
On a foundation.
<j`ey>
i just live in a normal house, boring
<Bitweasil>
We ordered it and it was installed a few months later.
<Bitweasil>
And honestly, I enjoy stuffing the hay in my collar and grossing out city folk. ;)
<Bitweasil>
I haul my trash once a year or less now.
<Bitweasil>
(anything organic goes to the property cats or compost, so it's just non-recyclable home waste, doesn't smell or anything)
<mrvn>
In germany we have compost, paper, packaging and real trash. I basically produce no real trash to speak of.
<mrvn>
(e-trash is different and a problem)
<j`ey>
nice, we managed to cut down on waste so only take it out 1-2 times a month (compared to the 4times the binmen come)
<Bitweasil>
I try to keep the e-waste down with repair and selling stuff, but it's a real problem globally. :(
<Bitweasil>
I had trash service for a while, but it got old hauling the can up the driveway to the street.
<Bitweasil>
And wasn't very useful anyway, we're bursty in trash. Nothing for a few weeks, then a sudden surge.
<Bitweasil>
I've just got an old covered pickup bed trailer that I take to the dump when it's full, and recycling is sorted separately, I sell the metals, and drop the rest off if I'm heading that way in town.
<mrvn>
There is no regular pickup for e-waste here. You have to bring it to a recycling station yourself.
<Bitweasil>
Glass and "weird" plastics are a pain, I have to drive a good bit for those, but I just take them if I'm going that way.
<Bitweasil>
Heh.
<Bitweasil>
eBay.
<Bitweasil>
Actually, look at Apple's trade-in program.
<Bitweasil>
If you're trading in something not-Apple, they'll send you a prepaid shipping label you can stick on a box.
<Bitweasil>
I use that for some of the stuff that local places won't take, power supplies and the like.
<Bitweasil>
No idea what they do with it, but it's more likely to get recycled than if I toss it in the dump.
<CoffeeMuffin>
I never throw away electronics.
<mrvn>
what do you do with a broken vaccum?
h4zel has quit [Ping timeout: 260 seconds]
<CoffeeMuffin>
repair it
<mrvn>
or table lamp.
<CoffeeMuffin>
table lamp?
<mrvn>
halogen one. the transformer is broken.
<mrvn>
It's cheaper to buy an LED lamp than a new bulb for the one the transformer blew and it's brighter too.
<Bitweasil>
Erm.
<CoffeeMuffin>
I never had a table lamp break, but probably keep it I guess.
<Bitweasil>
Halogens are just mains current.
<Bitweasil>
At least the ones I know of.
<CoffeeMuffin>
yeah, I thought so too.
<mrvn>
maybe it's something different, runs on 12V.
wand has quit [Remote host closed the connection]
<mrvn>
gets horribly hot as well
<CoffeeMuffin>
12V sounds like LED
<mrvn>
Nope, decades older than LED.
wand has joined #osdev
<CoffeeMuffin>
interesting.
<Bitweasil>
Huh, I've no idea what that is either.
<Bitweasil>
Halogen is just a bulb tech with a thick enclosure and a gas that directs the filament bits flying off back onto the metal.
<geist>
yah honestly at some point keeping things around that waste tons of power i think is more negatively useful than trying to keep using old things to keep it frombeing thrown away
<Bitweasil>
It runs hot as hell, they're quite hazardous, but they're very bright.
<geist>
i dunno when the crossover point is but lighting tends to pretty quickly fall in that bucket for me
<bslsk05>
www.amazon.de: Amazon.de Die Website wurde nicht gefunden
<Bitweasil>
12V could be HID?
<CoffeeMuffin>
Well, I have a 230V to 12V transformer lying around here, so that would not be a big problem. But I would not want to have something like that in the first place I think.
<bslsk05>
www.ebay.com: G4 24LED Light Bulb 2W 200LM Bi Pin Light Non-Dimm2V(Warm White 2700K-3100K) ZI | eBay
Payam3 has quit [Quit: Client closed]
<Bitweasil>
*nods*
<geist>
but it's that format. G4 lights i think. the original are like 35W halogen. 35W isn't a big thing except the thing is smaller than the end of your pinky
<geist>
so it gets really hot of that surface
bauen1 has quit [Ping timeout: 240 seconds]
<mrvn>
geist: yeah, they made LED things in G4 socket format because tons of people have those.
bauen1 has joined #osdev
<CoffeeMuffin>
yeah, lighting is probably one of those few things in the house you could replace once in a while
<mrvn>
A vacuum with a broken fan blade is toast too. Can't buy the part, can't 3D print it and not fly apart.
<mrvn>
I might not be able to buy new bags for it anymore too.
<CoffeeMuffin>
I collect electric motors
<Bitweasil>
CoffeeMuffin is really just a hermit at a junkyard. ;)
<geist>
<Egon> I collect molds and spores
<mrvn>
ESPACE
<CoffeeMuffin>
yeah, I have tons of electronics
<immibis>
mrvn: you could try cutting off the opposite fan blade to balance it :)
bauen1 has quit [Read error: Connection reset by peer]
freakazoid12345 has quit [Ping timeout: 252 seconds]
<geist>
and if it's one bladed, you can add a counterweight to the other side
<mrvn>
I'm sure it will perform really well with 0 blades.
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 272 seconds]
toulene has joined #osdev
bauen1 has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
freakazoid343 has joined #osdev
freakazoid343 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
sprock has quit [Remote host closed the connection]
sprocket has quit [Remote host closed the connection]
sprock has joined #osdev
dormito has joined #osdev
<heat>
does anyone know if samsung's kernel sources have any actual fun stuff in there?
mahmutov has quit [Ping timeout: 256 seconds]
<heat>
apparently they only release exynos sources which hints at fun stuff
<mrvn>
Sure, that part is intentional. But compare the two.
<heat>
lol
<mrvn>
gcc code fails if you enable trap on unaligned, right?
<geist>
yah it's assumed that you have it enabled on armv7
<mrvn>
or is that @ some bit in the opcode?
<mrvn>
-march=armv7 makes no changes
<geist>
i think that stmdb is okay. note it doesn't use a ldrd, beacuse i think that can trap on unaligned
<mrvn>
That stmdb writes 4 registers to the stack and then never touches them
<geist>
yah armv7 assumes you have unaligned accesses allowed
<heat>
I was very confused @ clang's codegen in the second function but that's actually pretty smart
<geist>
no not exactly. it writes to a slot the caller reserved
<mrvn>
gcc lines 7-10 are a NOP
<geist>
it pushed the function down, but then the ip register is *above* the current stack frame
<mrvn>
ip is where the stack as on entry, it undoes the sub
<mrvn>
So on entrey, sp = 0x1000, sp = sp - 0x10 = 0x0FF0, ip = sp + 0x10 = 0x1000
<geist>
oh nevwr mind it writes down
<geist>
yeah that's weird. i dunno what's going on there
<mrvn>
Does stmdb writes upwards or downwards?
<geist>
downwards
<geist>
been a while since i thought arm32
<mrvn>
Yeah, so it writes to the functions stack frame.
<mrvn>
gcc (just trunk?) seems to have huge problems with tiny functions. Seen that a bunch of times now.
<heat>
my phone's vendor just tarbombed me
<heat>
why
<mrvn>
I really like clangs get_sequenze_num(MessageHeader).
<geist>
basically setting the packed attribute on anything causes all the compilers to go nuts
<geist>
it's terrible hoestly because even if it knows the arch can do unaligned, it seems to go full stupid
<geist>
so it's a real issue for things like tcpip headers where you probably want them to be packed, but dont want to it keep generating bytewise load/stores
<geist>
to op0timize it you really want to memcpy it out into something aligned and parse it there
<heat>
why do you want tcp ip headers as packed?
<geist>
ethernet headers are packed iirc
<geist>
well, unaligned
<zid>
tbh I'd treat an ethernet header as a u8[] anyway becaues you need to nthos it and stuff anyway
<geist>
yah, or that
<zid>
and it may come off the wire into /memory/ unaligned if it's inside another protocol
<geist>
basically if you naievely mark it packed because of that you'll end up with terrible codegen
<mrvn>
In this case it's financial messages from a talk by Godbolt. :)
<heat>
wait, i'm confused now
<zid>
I'm not sure how you're going to get away from treating it as bytes
<heat>
are all network headers just implicitly aligned
<mrvn>
zid: You read from a socket into an aligned buffer. So you know the start is aligned.
<mrvn>
If it's e.g. UDP frames then every message will be nicely aligned.
<mrvn>
You know all about good network hardware. Good NICs can split the IP header and payload into separate buffers, right?
<heat>
yeah
<mrvn>
So what one maybe want to say to the compiler is: algin(8), padding(1)
<mrvn>
or 0
<mrvn>
pack the members but not the struct
<mrvn>
Then the compiler can reason about the offset of each member and use aligned/unaligned access as needed without going totaly bonkers.
<heat>
wow I think my phone's SoC code is fully open source
<heat>
kudos samsung
geist has quit [Ping timeout: 252 seconds]
Benjojo has quit [Read error: Connection reset by peer]
geist has joined #osdev
Benjojo has joined #osdev
mats1 has quit [Ping timeout: 252 seconds]
SanchayanMaity has quit [Read error: Connection reset by peer]
snickerbockers has quit [Read error: Connection reset by peer]