<bslsk05>
github.com: linux/entry.h at master · torvalds/linux · GitHub
<geist>
the reverse for it is `addl%sp@+,%sp`
<geist>
so it must somehow store the offset of the sp on the stack itself
<geist>
(args are left to right)
bradd has quit [Ping timeout: 260 seconds]
<geist>
the addressing modes on 68k made your head spin
bradd has joined #osdev
<zid>
can I get it in intel syntax? :P
heat has quit [Remote host closed the connection]
heat has joined #osdev
<geist>
tehre is sort of an equivalent in 68k land. motorola has their own format in their docs, and then there's AT&T syntax, which is mostly a clone of VAX syntax. similar to x86 AT&T syntax. for the same reasons
<zid>
yea
<geist>
the difference is gas actually accepts both at the same time
<geist>
since they seem to be mutually intelligable. probably because the directino is left to right in both
<zid>
oh is it? *deletes m68k*
* geist
rolls eyes
<geist>
motorola syntax would be something like (sp)+ or whatnot
<heat>
so i binge-wrote a whole driver and I don't know if it works
<heat>
it keeps breaking but i'm not sure if this is leftover stuff from the last vm reboot when I was passing through the nic
<heat>
fun thing: it kept reporting the link to be down, until I booted linux, then it started being up (correctly)
<heat>
something tells me it's not meant to survive multiple reboots without a pci reset
mats1 has quit [Ping timeout: 245 seconds]
mats1 has joined #osdev
knusbaum has joined #osdev
knusbaum- has quit [Ping timeout: 256 seconds]
epony has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
heat has quit [Ping timeout: 248 seconds]
Vercas5 has joined #osdev
Vercas has quit [Ping timeout: 240 seconds]
Vercas5 is now known as Vercas
zaquest has joined #osdev
the_lanetly_052 has joined #osdev
<geist>
so i still dont understand what it's doing but FWIW `clrl %sp@-` seems to be canonical for 'push a 0 long word on the stack' as a single word instruction (16 bits)
the_lanetly_052_ has quit [Ping timeout: 240 seconds]
<kazinsal>
that's AT&T syntax, right?
<kazinsal>
clrl is "zero longword", %sp@- would be using %sp for the register indirect predecrement mode
<geist>
yep.
<geist>
what i dont understand is why they do it, it doesn't seem to align the stack. only thign i can think is some later code in linux modifies that field
<geist>
such that on the way out of the exception some magic happens
<geist>
because on the way out of the exception tney do `addl%sp@+,%sp`
<kazinsal>
bwah
<kazinsal>
okay, that's weird
<geist>
i dont know the rules of how that works, it both modifies the sp because of post increment and also adds to it
<geist>
presumably it's well defined what happens in that case
<kazinsal>
yeah, I wonder what the order of operations is
<kazinsal>
I presume it's sp += *sp++
<kazinsal>
and not sp += *sp; sp++
<geist>
yah the programmers manual i have isn't really clear on it. but i'm guessing the rules are the stuff is handled left to right in that order, and complete
<geist>
things with complex addressing modes with more than one like this (VAX is an extreme example of it) have to have well defined rules
<geist>
68k for the most part only doens one <ea> per instruction, except instructions that explicitly have two <ea>s like movem
<geist>
so you can do lovely things like `moveml %a0@+,%a1@+`
<kazinsal>
it's a thing of beauty
<geist>
wait it's `move <ea>,<ea>`
<geist>
movem is a bitmap based move thing `movem <list>,<ea>` or the opposite
<geist>
`moveml %d0-%d7/%a0-%a6, %sp@-` pushes all the regs (minus a7 which is actually sp) to the stack, for example
<geist>
only 2 words too: the first one is the opcode + ea (unless the ea spills over) an the second word is a 16 bit bitmap
<geist>
the <ea> encoding is nice and regular
<kazinsal>
I can't remember, does 68k use a link register or does it push to the stack directly on a jsr?
<geist>
push stack directly
<kazinsal>
gotcha
<kazinsal>
guess the lr thing is a bit more risc-y
<geist>
yah also bsr. took me a while to grok bsr vs jsr (and bra vs jmp)
<geist>
and it turns out to be an efficiency thing: bra/bsr are hard coded to be PC relative, and take an 8, 16, or 32 bit offset (8 bit encoded directly in the instruction)
<geist>
jmp/jsr are more generic: `jmp/jsr <ea>`
<geist>
so jmp/jsr can do all of the same thing the 'b' versions can, because PC relative is one of the regular <ea>s but would take more space to encode the same thing
<geist>
very cute.
<kazinsal>
oho, that's clever
<geist>
alas gcc/binutils dont seem to be able to relax those. it hink they used to, but it seems gcc generates the full 32bit jmp/jsr because it doesn't know the range
<geist>
supposedly binutils can relax that to bra/bsr but seems to have forgotten how over the years
<geist>
iirc VAX has a pretty similar b vs j thing. almost eerily similar, like 68k straight copied it
<geist>
bra is really cheesily but nicely encoded: 8 bit opcode, 8 bit offset (all instructions are multipls of 16 bits)
<geist>
if offset == 0 then the next word has a 16 bit offset
<geist>
if offset == 0xff then the next 2 words have a 32bit offset
<geist>
cheesy, but gets it done. so much simpler than a mod/rm nonsense
<geist>
also has the funny property that you can't branch to the next instruction with a single word bra, because then it'd have to encode an 8 bit offset of 0, and it can't do that
<geist>
anyway, the TL;DR is 68k is like VAX lite, but still pretty nicely done
Vercas0 has joined #osdev
Vercas has quit [Ping timeout: 240 seconds]
Vercas0 is now known as Vercas
<kazinsal>
yeah that looks like a fun platform to hack on
<kazinsal>
kinda disappointing that the coldfire stuff never really went anywhere and also ripped out a good bunch of the more interesting stuff from the later 68k chips
<geist>
a bit late to the game, etc. but it's nice to go back and appreciate what folks used to really like about it
<gorgonical>
I'm reading about this idea for disaggregated memory called Kona. Basically you add a new level to the cache coherence model, which is remote memory. Sort of shove the infiniband model of smart controller with high-level semantics into the cache system: transparent access to remote virtual memory
<mrvn>
geist: have you looked if there is a small memory model where it assumes 16bit offsets are enough?
<mrvn>
(gcc)
panosdev has quit [Ping timeout: 272 seconds]
<mrvn>
Otherwise any branch between sections or compilation units has to be 32bit because gcc has no idea where the code might end up. LTO might shorten branches at link time. Otherwise I think you are stuck with 32bit offsets.
panosdev has joined #osdev
<mrvn>
geist: Have you finished you m68k disassembler? Is x == asm(disasm(x)) for all recognized opcodes?
gog has joined #osdev
enkeyz has quit [Quit: WeeChat 3.4]
enkeyz has joined #osdev
gildasio has joined #osdev
Burgundy has joined #osdev
pretty_dumm_guy has joined #osdev
nyah has joined #osdev
mrvn has quit [Ping timeout: 272 seconds]
mrvn has joined #osdev
netbsduser has quit [Read error: Connection reset by peer]
<bauen1>
if i understand c++ vtables correctly, they're essentially a table of all virtual methods as function pointers so if you have parent A with method f, and an inheriting class B that overrides f, then the vtable for B would contain a pointer to its own f method
hodbogi has joined #osdev
<bauen1>
now this is really annoying because it makes generating a callgraph for worst-case-stack-usage hard since everything under the sun suddenly starts using indirect calls
mahmutov has joined #osdev
<zid>
Yes, C++ is very difficult to reason about
<zid>
welcome to 1994
<bauen1>
yes and it's frustrating :(
hodbogi is now known as FatalNIX
<FatalNIX>
It's only 1994.. I thought it was 1993
<bauen1>
oh great and you can load them dynamically too "The actual set of valid vtable pointers for a virtual class, e.g. class Foo, cannot be built until runtime, when the vtables get loaded into memory and their addresses are known."
<FatalNIX>
Man
<FatalNIX>
I'd love to learn Rust but I have no reason why I really should.
<FatalNIX>
I sink into this paradox of things and additionally ponder why I'd love to learn it in the first place.
dude12312414 has joined #osdev
<j`ey>
just mess around with it?
<FatalNIX>
Yeah but I have other projects to work on
dude12312414 has quit [Remote host closed the connection]
<FatalNIX>
It's not as bad as say Haskell where I run out of disk space or reboot my computer before the download is ever finished for GHC, I've installed Rust before and just never used it XD
<j`ey>
then dont :D
<FatalNIX>
Rust looks kind of cool though tbh
<FatalNIX>
And from what I understand it is pretty viable for systems development
<FatalNIX>
I wonder if I can run it on one of my AVR chips or something.
<j`ey>
anyone what the difference between 'hidden' and 'protected' are in elf visibility?
<j`ey>
"STV_PROTECTED A symbol defined in the current component is protected if it is visible in other components but cannot be preempted." 'preempted'??
<clever>
that doesnt sound like something elf should be managing!?
<FatalNIX>
There is a visibility field in ELF
<FatalNIX>
unless that's not what's being referenced
<j`ey>
that is, yeah
<FatalNIX>
I usually only see readelf show "DEFAULT" there
<j`ey>
hitting an error with a weak + hidden symbol
<FatalNIX>
My chickens are going crazy. Had to investigate.
<FatalNIX>
I'm kind of wondering, why would you want something weak and hidden at the same time
<FatalNIX>
how would the symbol be replaced if the weak symbol is hidden
<bslsk05>
lore.kernel.org: [PATCH] module: use hidden visibility for weak symbol references - Ard Biesheuvel
sonny has joined #osdev
<FatalNIX>
Weird.
<kingoffrance>
"It's only 1994" amateurs!
Likorn has joined #osdev
nur has quit [Quit: Leaving]
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
GeDaMo has joined #osdev
sonny has quit [Remote host closed the connection]
<geist>
mrvn: well usual stuff (re 16bit branches). the compiler will use bra when it knows it's a local branch and can be easily reached in 8/16 but uses jmp or a 32bit bra (020+ i believe) for things that the linker resolves
<geist>
presumably the linker could relax those to 16bit bras if it had relaxation support. if you happen to branch to a nearby function, etc
<geist>
also i'm buildin for 010 right now which doesn't have a 32bit bra/bsr so it uses the jmp/jsr variant for unknown offsets. OTOH it's using the absolute jmp, but i'm also not building for pic
<gog>
mew
* geist
pets gog
* gog
prrs
<mrvn>
it might be able to relax bra but will not convert jmp to bra
<geist>
yah
<geist>
and tyrig to build with -fpic ends up with a bunch of linker errors i haven't bothered to debug
<mrvn>
Personally I think relaxing is the wrong way to go. Better to expand as needed aso you start of with the smallest code. But then it wouldn't be optional in the linker.
<geist>
the lack of 32bit bra in 010 i think really changes the codegen fairly substantially for pic
<geist>
well, can't expand as needed, because the ompiler doesn't know at codegen time how far away external references are
<geist>
same problem happens in x86, but x86 doesn't have as many options to relax to, so i dont htink it's as much of an issue
<mrvn>
try LTO. If everything is a local jump the compiler should do the right thing.
<geist>
never got LTO working on LK.
<geist>
i fiddle with it every once in a while but there was some reason it was an issue and i dropped it
<mrvn>
By expand as needed I mean the compiler should insert an 8bit branch and the linker then expands to 16/32 as needed.
<geist>
oh sure. but i think that's basically the exact same machinery as relaxing
<mrvn>
Avoids cases where you need 16/32 bit branch because other branches didn't relax to 8/16 bit. And they can't relax because your branch is 16/32bit.
* geist
shrugs
<geist>
either way, none of it works, so i suspect it broke somewhere along the way and no one has fixed it
<mrvn>
have you observed if any 16bit branches become 8bit?
<geist>
i dont have -mrelax set so i would not expect it to
<geist>
the compiler does however emit 8 and 16 bit branches all over the place for local stuff, branches within functions, etc
<mrvn>
I would be surprised if jmp/jsr gets relaxed.
<geist>
it could relax to a 16, but again would need the siwtch set
<mrvn>
just think changing a jmp to bra is a bigger change and probably not included in -mrelax. But that's just a wild guess.
<geist>
when i had the switch set i think it had actual linker errors, so i quit futzing with it, but that was like a year ago
<mrvn>
bauen1: worse. if a class is passed as one of its base classes then the vtable changes.
<geist>
but i'm also not building with -fpic, (which also generates linker issues) so it also seems to be totally happy using absolute jmp/jsrs
<geist>
but then jmp/jsr *could* do PC relative, but that may encode to a larger instruction since i think that would require an extra word to describe PC + 32bit offset
<geist>
vs a pure 32 absolute, which ends up being 3 words
<mrvn>
geist: with -fpric you probably would get a GOT and jump to register.
<geist>
yah the linker errors are all about got stuff. possibly i have to fiddle with my linker script to get it working
<geist>
was hoping it'd simply just start usig relative things, but seems to be more involved on 68k
<mrvn>
can't do relative if the memory model is 32bit.
* geist
nods
<geist>
anyway, i dont really care that much, just sort of an interesting aside
<mrvn>
I don't think gcc/clang do PIC code as "A0 = PC + #offset; jmp A0" on any arch. They always use a relocation.
<mrvn>
They only do relative when they can encode it in a single opcode.
srjek has quit [Ping timeout: 250 seconds]
<geist>
yah though of course bra/bsr can generally get to everything in 32bit, so i'd just generally assume the compiler would switch to that. at least on 020+
<geist>
on 010 i think you're hosed and have to use a GOT, because there's no 32bit bra
<geist>
which is possibly the problem i have here
<mrvn>
nod, but you don't have a 020. :)
<geist>
but then i also compile for 040 when running on qemu, and it has baically the same linkage problem
<mrvn>
Have you looked into the debian-m68k port if they have patched binutils/gcc?
<mrvn>
upstream might have bitrot.
<geist>
nah. i might fiddle with it later, but at the moment i'm trying to stay focused on getting the thing inf ront of me working without trying to get too side tracked
<geist>
it's more of a curiosity. a missed optimization
<mrvn>
Can't believe -fPIC isn't working for them at least.
gog has quit [Ping timeout: 248 seconds]
sortie has joined #osdev
teroshan has joined #osdev
<bauen1>
mrvn: you mean if i pass a Child to something that takes a Parent, then a different vtable is passed than normally ?
<bauen1>
vtables are even more infuriating as these are essential templates that get inherited from and have 1-3 virtual methods to override
<bauen1>
essentially there is no need for dynamic dispatch i think (apart maybe from the Thread class at the absolute bottom)
<bauen1>
*for my project
<mrvn>
bauen1: afaik yes. Think about multiple inheritance. There is no way to make a vtable that fits both parents.
<gorgonical>
This is a bit of a long shot: the pine64 board has a camera sensor interface that it says is based on i2c. I'm trying to understand the linux-supplied IRQ handler. I can't find a specsheet that explains why we *write* the status back to the status register
HeTo has quit [Read error: Connection reset by peer]
<gorgonical>
I more or less understand the camera description that we set up our dma regions and the camera signals via IRQ when a frame is ready. We check the status register to make sure, and then pass that off to higher-level code. But why the re-write to the status register?
HeTo has joined #osdev
<gorgonical>
AFAICT the status variable won't even change. Is it like an ISR register where writing to it triggers some action?
<j`ey>
to clear / ack?
<gorgonical>
j`ey: That's what I was thinking? But the manuals/datasheets are extremely sparse
gog has joined #osdev
HeTo has quit [Read error: Connection reset by peer]
HeTo has joined #osdev
<geist>
bauen1: see also virtual inheritance. it concerns what vtable to use when multiple inheritance is involved
<geist>
but without multiple inheritance then you dont get a variable vtable like that
<geist>
you have a single vtable, and the parent version of it just uses less entries
<geist>
since new virtuals declared in the child just add to the table
HeTo has quit [Read error: Connection reset by peer]
HeTo has joined #osdev
HeTo has quit [Read error: Connection reset by peer]
HeTo has joined #osdev
HeTo has quit [Read error: Connection reset by peer]
HeTo has joined #osdev
<mrvn>
type wise it's still a different vtable (type)
GeDaMo has quit [Remote host closed the connection]
<mrvn>
geist: isn't there also a way to (re)virtualize methods where casting to the parent type will change the virtual method that gets used? Even without multiple inheritance. Or was that only overloading a static method with a virtual one?
<bauen1>
there's only 206 indirect calls over the entire project so far, so i guess i might be able to get away with requiring manual annotation for those
<mrvn>
bauen1: you could add a concept to the method that encodes the stack requirement.
<mrvn>
require the annotation to be code
<mrvn>
also consider if you can do dependency injection. Inject code where you know the stack requirements across many classes
<bauen1>
mrvn: i don't quite understand what you would want to do with a concept or how that would help ?
<geist>
mrvn: i dont think so.
<geist>
though iirc there's something to do with which vtable you 'see' inside a constructor or desctructor
<geist>
but that's also one of those reasons why you shouldn't call virtuals inside those
<geist>
also iirc that's an job interview level quetion: how can you call a pure virtual method
<geist>
if you call a virtual function inside the constructor of an object with a pure virtual, or pass a pointer to this to something else that calls it
<geist>
since at that point the object has a vtable set up of the base class, even if a bunch of its entries are pointing to the pure virtual method
<geist>
or something like that. it's a Bad Idea. compiler will probably warn if you do it directly
<bauen1>
ok, actually compiling for the mcu leads to 691 indirect calls and 538, so perhaps not as fun
mahmutov has quit [Ping timeout: 256 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Likorn has quit [Quit: WeeChat 3.4.1]
srjek has joined #osdev
<bauen1>
looks like i'll have to do "what the linker does" and take care of local/global/weak symbols myself, so this is a longer journey
<bauen1>
but -fcallgraph-info=su also seems to give me enough information that I can potentially find all overrides of a particular method, not ideal for worst case stack usage, but easier than doing things manually
FreeFull has joined #osdev
Burgundy has quit [Ping timeout: 250 seconds]
<geist>
hmm, that sounds like a fun switch to play with
<mjg>
what has that option?
<mjg>
gcc 9.4 says no dice
<kazinsal>
might be -fstack-usage on older gccs
<mjg>
nice
<kazinsal>
fun trick is to follow that up with `find . -name "*.su" | xargs cat | column -t`