<bslsk05>
ARM-software/optimized-routines - Optimized implementations of various library functions for ARM architecture processors (62 forks/268 stargazers/MIT)
<klange>
The vector versions would be useful to me in userspace. The one I hacked up here is basically just "do as many 64-bit copies as possible, then as many 32, then bytes to the end" and that has helped a lot over just bytes
<bslsk05>
github.com: optimized-routines/memcpy.S at master · ARM-software/optimized-routines · GitHub
<geist>
what's interesting about that one is once you get into big copy territory (>=128 bytes) it just copies 16 bytes at a time and the last partial one it just overlaps with a previous copy
<geist>
isntead of doing some sort of bytewise thing at the end
<klange>
I should probably rewrite this in assembly as I have started to grok it. I've been toeing a fine line with GCC's attempts to optimze memcpy to call memcpy.
<geist>
the memsets observation that wasn't obvious is if yuou're setting zero it has an optimized path to use `dc zva` instead
<geist>
functionally similar to AMDs clzero (this further proving that AMD picked up more ARM stuff from their K12 project)
<klange>
I even threw in the flag to disable that one loop optimization strategy but apparently disabling that is not enough anymore, gcc is "too good" at detecting memcpy's?
<klange>
It's annoying having to check output so often to see if gcc decided a libc implementation should branch to itself
<klange>
how the hell have they not fixed this when it's _in an exported function of that name_?
<geist>
ah yeah. i think the genral solution there is build libc with -fno-builtin?
<klange>
that's too broad, so you need to be really careful and apply to individual files
<klange>
because sometimes you do want builtins, of the actual __builtin variety, and that _will_ remove those
<geist>
right
<geist>
makes sense
<klange>
I might wire my libc build into my tooling so I can add magic hints to individual files for that
<geist>
yeah
<klange>
like I have one that automatically builds binaries with -rdynamic if there's a hint comment, for my plugin-driven apps
<klange>
which used to be a few things but is now just the panel... the compositor used to use it when I had an optional cairo backend
<geist>
so haven't been having many cache problems with real hardware?
<moon-child>
ARM ARM = ARM something Reference Manual?
<geist>
that's very good to see
<geist>
ARM Architecture Reference Manual
* moon-child
nods
C-Man has quit [Ping timeout: 250 seconds]
<geist>
it's a doozy, 50MB, 8500 or so pages, etc
<geist>
it's a real test of a pdf viewer
<klange>
geist: Seems like gcc is doing the right thing where I use sync locks, and things are working nicely
<moon-child>
intel is like 5k pages
<geist>
klange: was going to point out a few subtle things you may have missed but can get awway with with just wonky crashy behavior
<moon-child>
xpdf deals with it ok, chugs a bit. Macos pdf viewer completely dies
<klange>
I think it helps that I may have even been over-eager in a lot of places.
<geist>
a) you should memory barrier (DSB) after modifying page tables before you tlb flush, etc. the page table walker may not 'see' changes your cpu has done
<geist>
b) you need to sync I and D caches when you write out pages that have code in it
<geist>
sync in this case means flush the Dcache to the 'point of coherence' and invalidate the icache
<klange>
that latter one got me good
<geist>
yah
<klange>
apparently gcc has a built-in for it, but I can't figure out what bits I need to set for EL0 to be able to use it, so I just shoved it in a new syscall
<geist>
yah it probabl wants to read something from CTR_EL0 or from the aux[] thing fro the os
<geist>
since it needs to know the cache line size and if the machine is VIPT/PIPT/etc
<geist>
which you can read out of the CTR_EL0 register
<geist>
(it's _EL0 for precisely this sort of thing)
<klange>
oh that might be it, I'll check again later, the syscall approach is working fine for now
<klange>
but I should make sure I support the built-in for ports
<geist>
but also means as the kernel writes out pages with +x bit it may want to also sync
<geist>
in case you're demand faulting stuff off the disk or whatnot
<geist>
this is one of those cases where if you dont do it it's very hard to reproduce a failing test case but will eventually bite you
<geist>
we had it broken on zircon for like 3 years before we noticed it. primarily trying to run on M1 which has a monster sized L1 icache (192KB), so tends to uncover this stuff more
<klange>
interesting, I got fairly consistent failures and was able to even identify what the problem was from how consistently / where they were happening
dude12312414 has joined #osdev
<geist>
yah if you get some wonky failures after you load some code it's one of those signs you may have a coherency issue
<geist>
thankfull dumping the icache is easy, and even doable from EL0
<geist>
there's no chance of corruptio since icaches can only have read-only data by definition
ox3h has joined #osdev
<ox3h>
hello
<klange>
I found I had to make sure I also cleaned the data cache first, but in the end it's all working - kinda important since my whole userspace is dynamically linked (which is probably why I was able to spot it quickly)
<geist>
hiya
<klange>
(I imagine even a big professional OS like Fuchsia isn't just throwing a complete desktop userspace at a new platform like I have been...)
<klange>
Can be a very noisy test case, but it sure will expose problems.
ox3h has left #osdev [#osdev]
sdfgsdfg has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
<klange>
Just a bit more doc cleanup and I think this'll be ready to merge. Some arch-independent changes are starting to leak into this branch
sprock has quit [Quit: brb]
<geist>
very cool
<geist>
i will be eager to try it out on my arm hardware. what are you doing about virtual display stuff? going to implement virtio-gpu?
<geist>
or will just run like butt on M1 for now
<geist>
i have a cavium machine i can run it on in KVM too, will be interseting to see how that performs
<klange>
I'll do virtio-gpu as I want the M1 hvf experience to be better - the memcpy fix helped a lot as it reduced the access traps (8x faster now!)
<klange>
but that'll probably happen after the merge
sprock has joined #osdev
<geist>
ah makes sense. even linux with the bochs-display was struggling a bit. seemed to have some sort of caching issue too, since was seeing the fairly obvious checkerboard blitting issues
<geist>
which is kinda more odd when you think about it because you'd think the trap stuff would serialize everything
<geist>
unless it was on the qemu side
<klange>
It's possible it's because I'm using an older qemu on the rpi, but I haven't had any issues with it there - could well have been broken since 6.0
<geist>
but in general from past experience with the number of bugs we've bumped into running fuchsia on top of HVF x86, i'd be not surprised if the relatively new ARM HVF solution isn't pretty buggy too
<geist>
i would most certainly not trust it for any sort of mission critical stuff
<klange>
when this is all cleaned up, I can start working on the RPi4 platform port, see how this fares on bare metal...
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
epony has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 245 seconds]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
nyah has quit [Ping timeout: 250 seconds]
srjek has quit [Ping timeout: 240 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
[itchyjunk] has quit [Read error: Connection reset by peer]
<bslsk05>
thehackernews.com: Dozens of Security Flaws Discovered in UEFI Firmware Used by Several Vendors
k8yun_ has joined #osdev
k8yun_ has quit [Remote host closed the connection]
xenos1984 has quit [Remote host closed the connection]
k8yun has quit [Quit: Leaving]
xenos1984 has joined #osdev
<klange>
-fsigned-char did not fix it, and I should see if it actually is happening on x86 but a different data layout is making it not result in a segfault
<klange>
it may just be that this has always been broken and the particular layout of my binary has resulted in a gap at just the right place
k8yun has joined #osdev
k8yun_ has joined #osdev
k8yun_ has quit [Client Quit]
<klange>
it happens on x86 too
<klange>
yay
<klange>
okay not an arch64 port bug, but something to look at in the upstream doom port; I'll poke the doomgeneric peeps - been meaning to send them my patchset anyway
<klange>
so it's literally the thing I said where it has _always_ been happening and the data layout changed with this build
<klange>
doom is full of stuff like this if you run more 'pure' source ports
<zid>
That's why I prefer to use incredibly anal compilers on incredibly anal systems if possible
k8yun has quit [Quit: Leaving]
* moon-child
turns on alignment checking on zid's cpu
<zid>
sadly, windows doesn't run with it enabled
ekathva has joined #osdev
ekathva has quit [Max SendQ exceeded]
ekathva has joined #osdev
<CompanionCube>
Jari--: isn't insyde the corp that got their source leaked previously
Vercas4 has joined #osdev
Vercas has quit [Ping timeout: 276 seconds]
Vercas4 is now known as Vercas
orthoplex64 has quit [*.net *.split]
wgrant has quit [*.net *.split]
gorgonical has quit [*.net *.split]
sham1 has quit [*.net *.split]
rustyy has quit [*.net *.split]
bauen1 has quit [*.net *.split]
froggey has quit [*.net *.split]
basil has quit [*.net *.split]
eryjus has quit [*.net *.split]
mavhq has quit [*.net *.split]
bxh7 has quit [*.net *.split]
ThinkT510 has quit [*.net *.split]
bgs has quit [*.net *.split]
zid has quit [*.net *.split]
Griwes has quit [*.net *.split]
bradd has quit [*.net *.split]
scoobydoo has quit [*.net *.split]
joe9 has quit [*.net *.split]
Mikaku has quit [*.net *.split]
Piraty has quit [*.net *.split]
les_ has quit [*.net *.split]
andrewrk has quit [*.net *.split]
sham1 has joined #osdev
mavhq has joined #osdev
bauen1 has joined #osdev
wgrant has joined #osdev
basil has joined #osdev
bxh7 has joined #osdev
rustyy has joined #osdev
joe9 has joined #osdev
froggey has joined #osdev
Mikaku has joined #osdev
ThinkT510 has joined #osdev
bgs has joined #osdev
bradd has joined #osdev
orthoplex64 has joined #osdev
zid has joined #osdev
Griwes has joined #osdev
gorgonical has joined #osdev
eryjus has joined #osdev
les_ has joined #osdev
scoobydoo has joined #osdev
andrewrk has joined #osdev
Piraty has joined #osdev
ekathva has quit [Ping timeout: 256 seconds]
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
sdfgsdfg has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
doppler has quit [Ping timeout: 268 seconds]
zaquest has quit [Remote host closed the connection]
sdfgsdfg has joined #osdev
doppler has joined #osdev
ss4 has quit [Quit: Leaving]
wootehfoot has joined #osdev
<klange>
re: framebuffer on hvf: found the trace for the relevant vmexit, and yes, QEMU is taking a data abort on every write to the framebuffer
gog has joined #osdev
Jari-- has quit [Ping timeout: 240 seconds]
<geist>
ah interesting
<geist>
wonder what's different with how it sets up hvf
<geist>
i'd have assumed the framebuffer would be a shared memory region that just gets slurped out by the VMM periodically
<klange>
This device, and presumably the others that just slap a memory region onto a PCI BAR and call it a day, effectively map that space as mmio and want to subscribe to writes to know when it is dirty
<klange>
In KVM, there's options to coalesce memory regions for this, presumably so you only get one update event as part of a larger write?
<geist>
yah maybe HVF doesn't have support for some sort of 'this is a bar but really it's memory'
<klange>
And that doesn't seem to exist / be supported under HVF, so you're getting the 'log' abort every. single. time.
<geist>
it should be marked prefetchable in the BAR, but shouldn't matter
<geist>
ah yeah, you said it 2 lines ago
<geist>
note that HVF on x86 i think is reasonably fast, but maybe it traps less for rep movs or whatnot
<geist>
i suppose to optimize it even more than a stp you could use a q vector move
<geist>
though that's only twice as fast as a stp
<geist>
since presumably what you're doing now to blit onto it is doing something like a doubleword store (stp instruction)
<klange>
for what it's it worth this isn't even doing the stp yet, so even just that improvement would be twice as fast - and what I have now is already 8x as fast as what I had previously
<geist>
yah
<geist>
that being said i dunno if vector instructions get much decode assist in EL2
<geist>
regular load/stores get a lovely assist: the ESR_EL2 register basically fully decodes what caused the trap
<geist>
doesn't in ESR_EL1, but for EL2 it has a bunch of extra fields that tell you which registers trapped, at what addres and what their storage size was
<geist>
it can't decode atomics or whatnot, but that's fine because the ARM ARM says you cant use atomics against device memory
<geist>
only normal, cached memory
<geist>
watching Komi Cant Communicate. it's cute
<klange>
i just crashed qemu :)
<klange>
yeah the abort handler did NOT like it when I tried to do 16-byte writes
<geist>
nice. well strike that
<geist>
i guess if it's effectively device memory then that's that
<geist>
how are you mapping it? normal? (wouldn't matter really)
<klange>
it does not matter :D
<geist>
yah but it might affect how the EL2 trap happens
<geist>
may be that vector stores against non normal memory trap differently
<klange>
I should have it mapped as some form of normal memory at the moment
<geist>
dunno what the order of operations are there: data abort beacause of missing page at S2 or data abort due to forbidden stuff against device memory. okay. normal memory
<geist>
(i forgot how forbidden load/stores against device memory look. undefined instruction?)
<klange>
I should just write a virtio-gpu driver so I can hand actual regulary guest memory to it and send flush commands, won't have this problem...
<klange>
that seems to be the expected thing to do anyway
<geist>
it's kinda neat with virtio-gpu. you can create as many displays as you want, for example
<geist>
and you can nicely do a double buffered output if you want
<geist>
or scrolling
<klange>
bga has a virtual viewport so you _can_ do that with scrolling... but I'd need to rethink some things in my compositor to do that nicely anyway
<geist>
yah iirc when you tell it to blit from an existing surface for which you have a handle to to a 'scanout' object you can give it an offset and stride
<geist>
so you could build a scroll in any direction with that
<geist>
or double buffer by just blitting from a different backing buffer though it wont redraw until you tell it to, so there's kinda no problem using a single buffer i guess
<geist>
side note: i haven't looked at the virtio-input stuff but now that you've written a driver i have a few questios
<geist>
a) what are the keyboard scancodes? generic, defined by virtio?
<klange>
Linux's HID codes.
<geist>
b) virtio-tablet, what's the coordinate system?
<klange>
It gives you max x and max y, which are generally 0xFFFF, and that maps to the viewport by lerp.
<geist>
i wonder what happens if you create multiple viewports with virtio-gpu. maybe only binds to the first one?
<klange>
which is the same as how a bunch of the other absolute mouse things work
<klange>
when i tried with a different display + tablet previously, it mapped them on top of eachother and was completely useless
<geist>
the virtio-mouse one is probaly just a delta pixel thing
<klange>
I think that was vmmouse? And I don't recall what display device, I was just being silly and asking for another monitor.
<klange>
virtio-mouse is a normal relative mouse, yes
<geist>
cool. i remember looking at virtio-serial at some point andit was annoyingly complicated
<klange>
This stuff is all completely undocumented so I had to _read the source_ to figure out what anything did. The Virtio doc sections are just like "this is a thing that exists" with no details on what they send
<geist>
yah the virtio spec for the input stuff is pretty much empty indeed
<geist>
in general i dont think much of the virtio stuff outside of -net -blk and -scsi get a lot of use elsewhere other than qemu
<geist>
and i think more and more serious VMMs use virtio-scsi instead of -blk or nvme
<klange>
fun fact, these drivers aren't even interrupt-driven _because I couldn't figure out how to do interrupts_.
<geist>
hah for pci on that machie it'll be MSI
<geist>
though there are 4 PCI irqs statically assigned to the gic and there is a mapping of 'slot' to irqs, so you can probably fudge around and figure out which ones are mapped
<geist>
for virtio-mmio there is simple a IRQ reserved for every mmio aperture
<klange>
I mean I couldn't figure out how to ask for them in the first place, but I also haven't done any of that ^ yet either
<geist>
yah i was going to figure out MSIs next and then the new PCI bus asignment stuff will be finished
<klange>
I got as far as enabling the interrupts for the timer, which is at a fixed irq... and the I blindly just did that on all the CPUs and that seems to work?
<geist>
yep. a bit of background there on gic is there are three ranges of irqs: 0-15 are SGIs (software generated interrupts), used for inter processor interrupts.
<geist>
16-31 are PPIs (private peripherals). per cpu. stuff like timers and debuggers
<geist>
32+ are SPIs (something peripheral interrupts) which are normal hardware irqs
<geist>
so the timer you were using ws probably somethingl ike vector 29 or so
<geist>
it being a PPI
<geist>
SPI = shared peripheral interrupts
<geist>
that also means that vectors 0-31 are effectively per cpu
<geist>
and in the gic register layout they're a bit separate for precisely that reason
<geist>
the enable/disable bits and whatnot being private per cpu
<klange>
neat; I'm probably uselessly rewriting global configs in this, but i'll clean that up later with the rest of the gic setup :)
<geist>
i did look into generating MSIs on GICv2. it's actually trivial. basically you configure the MSI message to literally write the interrupt # into register in the GIC.
<geist>
there's no notion of cpu affinity or whatnot, you have to have set that up in the GIC itself, which you can
<geist>
in GICv2 there's iirc a 8 bit bitmap for every vector that says which of the 8 cpus to deliver it to
<geist>
but nice things about GICs is they can support a fairly huge number of interrupt vectors (8192 is i think the max) and i've frequently seen some on various SoCs configured up to 900 or 1000 or so
<geist>
so it's fairly easy for the designer to just reserved a bunch of vectors for MSI messages. basically not wired up to anythign externally, just there as a thing to trigger
[itchyjunk] has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
GeDaMo has joined #osdev
zaquest has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
<geist>
oh interesting. reading the gicv2 docs a bit closer it looksl iek if you mark an individual irq as targetting more than one cpu
<geist>
it may actually fire simultaneously on all the targetted cpus
<geist>
but it guarantees that only one of them will get a valid IRQ number when reading the GICC_IAR. the other cores will get a spurious interrupt
<geist>
basically, it's not assining irqs to cpus dynamically, it's doing a stampede and letting the first one win
<geist>
i'm fairly certain gicv3 does not do this, or at least as something smarter
ekathva has joined #osdev
Oli has joined #osdev
marshmallow has joined #osdev
marshmallow has quit [Remote host closed the connection]
marshmallow has joined #osdev
dormito has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
sdfgsdfg has joined #osdev
ss4 has joined #osdev
pretty_dumm_guy has joined #osdev
wootehfoot has quit [Ping timeout: 256 seconds]
ss4 has quit [Quit: Leaving]
dennis95 has joined #osdev
wootehfoot has joined #osdev
ElectronApps has joined #osdev
ElectronApps has quit [Quit: Leaving]
ElectronApps has joined #osdev
ElectronApps has quit [Remote host closed the connection]
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
ekathva has quit [Ping timeout: 256 seconds]
xenos1984 has quit [Remote host closed the connection]
nyah has joined #osdev
xenos1984 has joined #osdev
heat_ has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
dennis95 has quit [Read error: Connection reset by peer]
dennis95_ has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
heat_ has quit [Read error: Connection reset by peer]
<gog>
if it's not capable of what you're telling it then yes
<nick64>
Any register that device *must* write at request to be compliant?
<heat_>
the BARs it implements
<heat_>
the command register probably
heat_ is now known as heat
<nick64>
Okay.. I was hoping for something less intrusive
<nick64>
Let me backup the BAR and write to it then
<heat>
why do you care?
<nick64>
I didn't want something to crash
<nick64>
Or make it less likely to crash
<heat>
what are you doing?
<nick64>
I don't care much though
<nick64>
Just a PoC of PCIe
<nick64>
Nothing important
<heat>
btw the latency timer is defined by the spec as hardwired to 0
<heat>
makes sense why writes don't work ;)
<nick64>
Even the BASE_ADDRESS_3 write is not reflecting
<nick64>
I wrote all Fs. It was supposed to return the bits indicating size right?
<heat>
can you do lspci on the device?
<nick64>
Yeah
* nick64
In fact I got the DBDF from lspci
<nick64>
sudo lspci -s 0000:02:04.00
<nick64>
02:04.0 SATA controller: VMware SATA AHCI controller
<heat>
BAR3 isn't implemented by AHCI controllers
<heat>
at least not by standard ones
<nick64>
I see. I randomly chose 3 (not first to 32 bit ones) so that I don't crash something
<nick64>
Same observation for BASE_ADDRESS_1 as well
<nick64>
Btw if the lspci is showing that the ID is starting with 0000: it means it is insecure right?
<heat>
huh?
<heat>
what's insecure?
<nick64>
The OS that configured the PCIe device
<heat>
why is it insecure?
<heat>
which ID?
<nick64>
By assigning it to 0000, isn't it giving the device full access to system memory?
<nick64>
Domain ID
<heat>
no
<heat>
every PCIe device can access every single byte of system memory if it's not behind an IOMMU
<heat>
(if you let it access memory, that is=
<heat>
)
<heat>
that's also not a domain ID
<heat>
that's not even a thing in PCIe
<heat>
that's the segment
<nick64>
If that is not behind an IOMMU? You mean hardware or kernel config to enable IOMMU?
<heat>
you need hardware (chipset I believe) and kernel support
<nick64>
What is that ID if not Domain ID? Manual told me it is domain ID
<nick64>
2>&1 lspci --help|grep -i domain
<nick64>
-D Always show domain numbers
<nick64>
-s [[[[<domain>]:]<bus>]:][<slot>][.[<func>]] Show only devices in selected slots
Oli has joined #osdev
<heat>
that's wrong then
<nick64>
So my harware has IOMMU, and I thought Linux kernel default config is to enable IOMMU. What could possibly be the reason the device is not in separate address space?
<heat>
it's called a segment ID (see the PCIe, ACPI spec)
<nick64>
A question based on a wild guess, is this segment ID repurposed as a domain ID?
<heat>
probably just a different name
<heat>
i've had to explicitly enable the iommu
<heat>
intel_iommu=on in the cmdline
<nick64>
I see. I have a HW IOMMU, and I have enabled IOMMU for the VM, so platform side is taken care of. Should I explicitly tell the Ubuntu entry of GRUB or something to enable IOMMU for kernel?
<nick64>
(in VMware settings I have enabled IOMMU and vtx for the vm)
<heat>
yes
<heat>
but the BARs still won't have their own address space
<nick64>
Yeah BARs are device side and not system mem side, I suppose
<nick64>
I wonder why distros don't configure themselves to boot with IOMMU by default, and expect users to enable it
<nick64>
At least a buggy device firmware won't be able to drop ransomwares
<friedy10->
How can I change the memory protection flags for device drivers in linux?
<friedy10->
Like devices that use devm_ioremap.
k8yun has joined #osdev
srjek has joined #osdev
k8yun has quit [Quit: Leaving]
k8yun has joined #osdev
matrice64 has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
Oli has quit [Quit: leaving]
mahmutov has joined #osdev
gwizon has joined #osdev
gwizon has quit [Client Quit]
Terlisimo has joined #osdev
<catern>
if you saw an OS that used the word "precess" to refer to a process that is currently being set up and not yet running, would you think that's overly cute?
<heat>
what
<heat>
precess is stupid because you just read it as process the first few times
<heat>
source: me rn
<GeDaMo>
And by the time you stop doing that, the process is set up and running :P
<heat>
:D
<heat>
but yeah I don't see a reason why you'd want to refer to a process as precess except being cute
<heat>
and nothing in osdev is cute
<catern>
well it's something that is an omnipresent concept in my OS
<catern>
a process which is not yet running code on its own
<heat>
that's for web development, not manly operating system development
<heat>
we use K&R C
<catern>
so I need some short name for such a thing
<heat>
catern, call it process lol
<heat>
if you're doing process construction the way I think you are, the only difference between a precess and process is that it doesn't have threads nor memory mappings of an executable
<heat>
does a process stop being a process because it doesn't have an executable or threads yet? i'd disagree
<catern>
i agree that's the only difference, but I guess the issue is that in my OS a precess might never actually become a process - it might be created, used, and die without ever getting threads/an executable
<heat>
yes but IMO if you go down that route, it's still a process
<j`ey>
how will it be used?
<GeDaMo>
Always the bridesmaid, never the bride :P
<heat>
at the end of the day, a process is context with an ID
<catern>
well if I have code that's manipulating both precesses and processes... it's confusing to call them both processes
<catern>
(or at least I think it will be)
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<heat>
why? what's the difference between a precess and a process at the end of the day?
<heat>
a precess is just a process with an empty/not-started thread list and a not-finished/non-existing memory mapping of an executable
<heat>
i'd expect the API to be exactly the same
<catern>
well a precess you can manipulate by poking around in its internals and doing things with its resources, a process you can only manipulate by sending it signals
<heat>
ok
<heat>
I disagree with that approach but it's still the same thing
<heat>
just that the precess is a process that finished construction
<catern>
and has more APIs available for manipulating it
<heat>
(I disagree because if you're throwing away all the capabilities that allow you to load an executable and create threads for another process, you're losing a lot)
<heat>
all an ELF loader needs is mmap(process_id, ...), create_thread(process_id, ...), and possibly read/write_memory(process_id, ...)
<heat>
no reason you'd need more APIs
<catern>
i'm not sure what you mean
<heat>
at least not as actual kernel level APIs
<heat>
well you're doing ELF loading in user-space right?
<catern>
yes (morally, yes, anyway)
<catern>
but also all the other preparation of process stuff, like sticking file descriptors into it or giving it a user or things like that
<heat>
an ELF loader just needs a memory mapping primitive, a create_thread() primitive, and a read/write_memory(process) primitive
<heat>
sure
<catern>
I see
<heat>
that can all be arranged by just having every system call take a process handle
Vercas has quit [Remote host closed the connection]
<catern>
right, that's what I do
<catern>
so is your argument just, I should be able to create_thread and memory map after a process is already running?
<heat>
there's no need to throw all that powerful API away after construction
<heat>
yes
Vercas has joined #osdev
<catern>
that's an interesting and fair point, I'll have to think about that...
<heat>
of course you may want to restrict "remote system calls" to direct children with the same uids, or processes that are being debugged by $current_process, or an arbitrary limitation that was imposed by a security model of some sorts
<catern>
sure, of course (in my case just a capability system)
matrice64 has joined #osdev
<catern>
counterpoint, I think it's a great simplification on the implementation-side to be able to do: I'll make a bunch of calls with this handle, then I'll *consume* this handle as my final step, to create something new
<catern>
(and maybe I can have a debugging API where I can pause the new thing to get the handle back)
<heat>
ok but anyone that has that handle can still do the syscalls
<catern>
sure and they'll fail, that's what I mean by consume
<heat>
i don't see how that is useful
<heat>
how do you have a handle that arbitrarily stops working?
<heat>
if you have a handle, it should work
<catern>
i mean, when a TCP connection is broken, i stop being able to write to it... doesn't seem different?
<heat>
if you want to throw the handle away, you close it. boom, no syscalls can be done on that process any more
<catern>
implementing "I can change the memory map of a process at any time even while it's executing" is substantially more complex than "I can change it while it's not executing"
<heat>
why is a handle like a connection? that's not what a handle is
<catern>
that's the reason why
<heat>
how is that more complex?
<heat>
processes are not single threaded
<heat>
you'll still need to deal with the memory map changing under you
<heat>
even if you're a POSIX system
<heat>
because of threads you need to deal with everything that can change because of a system call change under you
<catern>
heat: okay, that seems plausible
<catern>
but, actually, I think the question is still:
<catern>
what do I call the "I can send a signal to this process" handle and what do I call the "I can change this process's memory map" handle?
<heat>
process handle :)
<heat>
you can, for example, have different policies based on the syscall (regular vs IPC for example)
<heat>
you can also have an ipc handle and a process handle
<heat>
but I think having a process handle and then have your raise_signal() syscall take those is cleaner
<catern>
but they're two different handles
<catern>
they should have different names because they have radically different level of capabilities
<catern>
but actually now I've got it, I've completely got it: they should be called, respectively, "pid" and "process"
<heat>
catern, they're a handle to the same thing IMO
<catern>
heat: thank you for making me think about this!
<catern>
heat: a handle to the same thing - maybe in some sense
<catern>
but a pid is much looser in its referencing
<heat>
this is fun to think about :)
<heat>
maybe a handle could have individual capabilities?
<catern>
i'm not sure what you mean individual capabilities? you'd want to be able to have them separately, so that would imply two different kinds of handle, right, one which has just the pid capability and one which has both process and pid?
<heat>
process handle would have multiple capabilities
<heat>
i.e you could have a read only process handle, or a process handle that can only do IPC
srjek has quit [Ping timeout: 240 seconds]
mctpyt has joined #osdev
<catern>
oh, sure, I see, yes
<froggey>
a capability is typically a resource + a set of permissions
dennis95_ has quit [Quit: Leaving]
heat has quit [Remote host closed the connection]
heat has joined #osdev
zaquest has quit [Remote host closed the connection]
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
matrice64 has joined #osdev
zaquest has joined #osdev
nomagno has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
[itchyjunk] has joined #osdev
dennis95 has joined #osdev
mctpyt has quit [Ping timeout: 256 seconds]
vdamewood has joined #osdev
srjek has joined #osdev
dormito has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
[itchyjunk] has quit [Remote host closed the connection]
srjek has quit [Ping timeout: 240 seconds]
terminalpusher has joined #osdev
<geist>
good morning folks
<g1n>
hi geist
dude12312414 has joined #osdev
* vdamewood
gives geist an orange.
terminalpusher has quit [Remote host closed the connection]
<kazinsal>
an orange a day keeps the hackernews away
<geist>
yay orange
<geist>
i love oranges
* vdamewood
gives gog and orange... fishy.
<vdamewood>
a/and/an/
<vdamewood>
mmmm.... salmon.
<GeDaMo>
Goldfish? :P
<GeDaMo>
What does the a/ command do? :|
<vdamewood>
s/a/s/
<vdamewood>
Well, Goldfish are certainly better than silverfish.
<FireFly>
heh
<FireFly>
also nom, salmon..
<geist>
salmon is a regional dish up here
<geist>
salmon this salmon that
<vdamewood>
Where I live, people care about the specific species of Salmon.
<vdamewood>
Coho vs Chinook vs Steelhead vs Sockeye
<geist>
yah
<geist>
there's a neat fish ladder in town with a window you can look into and see em swimming by
<geist>
different times of the year you get different species
<vdamewood>
geist: You're in my neighborhood, aren't you?
<geist>
seattle, it's the ballard locks i was thinking about
<kazinsal>
there's definitely at least half a dozen PNWers in here
<vdamewood>
Portland. So yeah.
<geist>
(though i moved out of seattle last year)
<geist>
kazinsal: side note, i assume vancouver and victoria people consider themselves PNW?
<vdamewood>
That's something I've wondered about myself.
<kazinsal>
yep
<geist>
though i figure for rest of canada its usually just 'BC' right?
<geist>
or do you say west coast?
<kazinsal>
the geopolitics of regional naming conventions in canada is a bit of a mess but yeah, most of the country considers us the west coast or just BC
* gog
chomps orange fishy
<vdamewood>
Alberta is the Texas of Canada.
<kazinsal>
whereas us BCers use either more specific local regional naming but generally consider ourselves to be more PNW than anything else
<geist>
makes sense
<vdamewood>
'Lower mainland'
<kazinsal>
we have a mountain range and three dead provinces between us and the rest of canadian civilization
<geist>
not much population in BC outside of vancouver and victoria though right? most of the rest of it is just mountains?
<kazinsal>
about a million and channge outside of the two big cities yeah
<kazinsal>
there are a handful of smaller 100-150k cities in the interior but they're not growing
<geist>
oh that's a bit more than i thought
<geist>
but i guess the sum of the towns thats not too surprising
<vdamewood>
I hear BC's popular for skiing and snowboarding.
<kazinsal>
yeah, it's a solid number but it's also primarily because BC is just geographically a large area
<geist>
even more so on a mercator projection!
<geist>
if i look at a map for it i can't comprehend how large it is. and yeah there's a lot of flat interior up in there isn't there
<geist>
i usually only consider the part of BC thats roughly east of vancouver
<kazinsal>
haha, yeah, there's basically a handful of corridors of civilization between a whole bunch of mountain ranges
<geist>
even with the right projecction it's still pretty much the size of all the western states in the US
* vdamewood
points out to geist that Prince George exists.
<vdamewood>
And PG has a population > 5
<kazinsal>
regrettably, prince george does exist
<kazinsal>
actually as far as small interior cities goes, it's not the worst
<kazinsal>
kamloops. kamloops is a depressing place to visit.
<geist>
PG looks like has a few malls and a canadian tire
<geist>
so it's civilization
<geist>
i had read somewhere long ago that indoor malls were relatively more popular in places where it gets frickin cold
<geist>
since you can go inside between stores
<vdamewood>
Makes sense
<vdamewood>
Hell, Alaska has a whole town in a single building.
<kazinsal>
yeah, Toronto has a whole underground mall complex
<kazinsal>
it's really neat, connects several underground malls and various other buildings with giant pedestrian tunnels
<kazinsal>
yeah, the great lakes are responsible for the cold climate there
<vdamewood>
You've got to be fsking kidding me. I looked it up. Torongo is further south than PORTLAND.
<kazinsal>
yep
<vdamewood>
Toronto*
<vdamewood>
Okay... I'm going to try and find the mid-to-major city on the Pacific coast that's closest to Toronto in latitude.
<GeDaMo>
Isn't Torongo that character in Futurama? :P
<j`ey>
toronga leela
<vdamewood>
GeDaMo: Nope. Toranga
<GeDaMo>
"Turanga"
<vdamewood>
Well, that was an interesting learning Experience.
<geist>
yah seattle is farther north than maine, etc
<vdamewood>
Toronto is roughly the same latitude as the nebulous border between central and southern Oregon.
<geist>
but it's all about what the large mass of land to your west/northwest is with weather in NA
<geist>
yah i rmember it being roughly level with eugene, or maybe salem
<Griwes>
also seattle is roughly as far north as berlin or warsaw
<geist>
yah i usually think it's basically north france
<Griwes>
I remember my grandma's reaction of "but that's so far north!" when I visited Seattle the first time
<GeDaMo>
I'm in Aberdeen in Scotland and I'm slightly to the North of Edmonton
<GeDaMo>
gog's a bit further North though :P
<Griwes>
a lot of people have this image of the us/canada border being as far north as the middle of scandinavia
<geist>
it was enough of a jump for me that in the deep of winter/height of summer, the days are still unusually short or long for me
<vdamewood>
gog: Are you in Reykjavik?
<vdamewood>
(or one of the smaller towns?)
<Griwes>
europe and north america have such massively different sizes that people just have a hard time realizing the difference
<geist>
i tend to think of it as US/canada is unusually cold given it's latitude, and europe is unusually warm
<gog>
vdamewood: rvk
<geist>
but a lot of that has to do with the temp of the water surrounding it. and north pacific is cold
<vdamewood>
I have a friend from Slovenia. Her parents called her concerned because of a disaster in Florida once.
<vdamewood>
She had to explain that the disaster was thousands of km away.
<gog>
64°N
<gog>
ish
<GeDaMo>
57°N
<gog>
idk if i'm the furthest north osdevver, there might be a lurker in here from akureyri or vestfjirði
<Griwes>
yeah, my second grandma was very concerned about me during this fall's tornado season in the east
<Griwes>
...I'm in California
<geist>
FIRE TORNADO
* vdamewood
fires the tornado for poor work performance.
<Griwes>
you can't fire the tornado, it quits
* Griwes
immediately goes to rewatch the sabrina 'mfire' video
<vdamewood>
Bird-cage, m-fire... umm...
<geist>
oh side note i was blabbing before about salt licorice i had before and whatnot from finland. i have since gotten some of it. interesting
<vdamewood>
I forgot what she thought the aviary was.
<geist>
cant say it's good but it's kinda addicting
<vdamewood>
geist: Like tobaco!
<gog>
yusss salmiaki
<gog>
my favorite candy is a salted licorice stick with a chocolate bar moulded around it
<gog>
draumr
<GeDaMo>
"It tastes like grandma!" :P
<vdamewood>
My favorite Candy is called Swedish Fish... But it's neither Swedish, nor Fish.
<vdamewood>
I'll be damned. Is is Swedish.
<vdamewood>
It* is
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<FireFly>
I'm not sure if it's the same ones, but you can find red gelatineous fish candy in the loose-weight candy section of the grocery store at least
<gog>
yes
xenos1984 has quit [Read error: Connection reset by peer]
<bslsk05>
en.wikipedia.org: Swedish Fish - Wikipedia
<vdamewood>
Wikipedia says it was made by a Swedish company for the US market.
<vdamewood>
So, not surprising it's not so big in Sweden.
<FireFly>
checks out
<gorgonical>
talking about treats, I wish I could get my hands on hakarl regularly to force my friends to know it, too
<gorgonical>
"treats" used generously here
<gog>
i haven't tried it
<gog>
one of our friends visiting from NY tried and she didn't hate it
<gog>
which i was surprised by
<gorgonical>
I made the incredible mistake of trying it first by mail; I ordered some. Naturally it was rotten but I didn't know that. Like eating an ammonia tablet. The stuff I had in the market near the harbor in reykjavik was not bad
dennis95 has quit [Quit: Leaving]
<gog>
next time i go to cafe loki i'm gonna try it
<gog>
they serve it up with that liqueur... uhh brennavin i think
<gorgonical>
how popular really is that opel (sic?) stuff? It's... caraway flavored?
GeDaMo has quit [Remote host closed the connection]
<gog>
popular enough, they sell it at every market and corner ship
<gog>
shop
<gorgonical>
Only time I had some was in some legit tavern where the "cheapest beer" could be found. A pint of gullfoss and a shot of this opel stuff for like 1,400isk
<gorgonical>
An interesting country I'd like to spend more time in if I could
<gog>
come back and i'll take you to café loki
<gog>
:p
<gog>
they have a great kjötsúpa
<gog>
nice little place, right across the street from hallgrímskirkja
xenos1984 has joined #osdev
<Bitweasil>
You're just keyboard mashing now. :p
<gog>
gúð hjalpa mér :p
<gorgonical>
wat: "rye bread icecream"
<gog>
ohh! yes i tried that
<gog>
it's really good
<Bitweasil>
I would love to take a motorcycle trip around Iceland.
<Bitweasil>
There are some tours that do it.
<gog>
it's like a frozen extra-sweet bread pudding
<gorgonical>
ahh
<gog>
gotta let it warm first though, the way they serve it is in little cups straight from their deep freezer :p
<gorgonical>
Bitweasil: I really wanted to do four or five days backpacking in the big parks. I saw the westfjords in a failed attempt to see puffins and was totally awestruck by the landscape
<gog>
haven't been there yet
<gog>
my wife wants to take me either there or seyðisfjörður this summer
<Bitweasil>
Yeah, couple kids and traveling drops off. :/
<gorgonical>
I drove in a manual toyota yaris to latrabjarg because I was told there would be puffins. I feel I was pranked
<gog>
did you take the long way around snæfellsnes/
<gog>
or over the pass?
<gog>
also if you wanna see puffins you can in reykjavík, there are some protected nesting grounds at the end of seltjarnarnes and if you don't mind breaking the law a little you can go see them
<gog>
usually in july or august
<gorgonical>
I think I took the path over the top of it. we made the trip in just a day so we needed to save time
<gog>
ah fair
<gorgonical>
which was also a mistake lol
<gog>
yeah it's not an easy drive lol
<Bitweasil>
Sounds fun. :D
<Bitweasil>
Maaaaaybe not in a Yaris, though.
<Bitweasil>
They have, like, 15hp on a good day?
<gog>
nah rent a hilux next time :p
<gorgonical>
Esp. since I hadn't reeally driven a manual in a good ten years
<Bitweasil>
I've never driven a Hilux and I so want to.
<gorgonical>
So there was a little clutch grinding in the roundabouts of reykjavik for a while
<Bitweasil>
Bulletproof tanks, they are.
<Bitweasil>
Clutches don't grind. ;)
<gorgonical>
Well let me tell you something was a-grinding
<Bitweasil>
I... no longer drive any modern manuals, but I do drive unsynchronized old manuals on occasion.
<Bitweasil>
Double clutch both up and down.
<Bitweasil>
Synchros must have been shot.
<gog>
i had a mitsubishi mighty max in high school. half the synchros were fucked
<Bitweasil>
Yeah, I learned to drive on sticks with beat up synchros, had to double clutch into 2nd if I wanted to get there from speed.
<gog>
had a hell of a time getting it into 1st gear
<Bitweasil>
Turns out, this is an *exceedingly* useful thing to have learned.
<Bitweasil>
Eh, if you're rolling, you don't need 1st.
<Bitweasil>
Lug 2nd.
<gog>
true
<Bitweasil>
Some stuff has a creeper gear, it's like a super low first you never use, unless you're running in a field with pickers.
<Bitweasil>
(basically, it idles at picker speed in that gear)
<gog>
i beat the shit out of that truck. drove it a few miles without oil one time. didn't even notice the filter seal had popped until i got home and saw the pool of oil :|
<Bitweasil>
You double up the oil filter o-ring?
<gog>
i hadn't even changed it since i bought it lol
<Bitweasil>
That's the usual failure there.
<Bitweasil>
Oh.
<Bitweasil>
... someone probably did, then.
<gog>
probably
<Bitweasil>
If you've got two of the square O-rings (square-rings?), they'll work for a while, but eventually enough oil pressure can push the lower one out, since it's not being held by the channel for it, and, whoops, there goes the oil.
<Bitweasil>
(also, reasons to oil the gasket before you install it - way more likely to stick if it's not been oiled)
<gog>
idek how many miles that oil and filer had on it :|
<gog>
probably way too many lol
<Bitweasil>
I've seen coal black oil in a diesel before.
<gog>
but it kept on goin. engine was a beast
<Bitweasil>
Never a good sign.
<Bitweasil>
Oh, yeah, those little pickup motors take a beating and come back for more!
<gog>
ran it overhot stuck in traffic for an hour in minneapolis once
<Bitweasil>
It wasn't "Very dark brown." It was absolutely jet black.
<Bitweasil>
Crank the heater, open the windows.
<Bitweasil>
Bonus cooling.
<Bitweasil>
Then check your fan clutch.
<gog>
didn't help, it was a coolant leak
<Bitweasil>
Oh. :/
<gog>
the bypass hose around the carb burst
<gog>
had a temperature controlled choke
<gog>
didn't work right either
<gog>
it would try to keep running after i shut it off XD
<Bitweasil>
Ugh, yeah, I know those hoses. :/
<Bitweasil>
I've had to bypass a few of them too.
<gog>
took me a minute to find it too
<heat>
geist, how important are linker relaxations for riscv codegen?
<geist>
pretty important, thougth i dont think they're required for anything
<geist>
i think it can collapse a bunch of sequences, like calls to faraway code and whatnot
<geist>
i think that's a biggie, because you end up with two vs one instruction sequences
<geist>
and of course the gp relative thing, but i thik that's fairly minor
srjek has joined #osdev
<geist>
it seems trange when first readig the ISA, but `jalr` instructions always take a register as base and always take a 12 bit signed offset
<geist>
basically reuses the same address computation logic as a load/store
<heat>
well this is kind of crap
<heat>
lld doesn't have riscv relaxation
<geist>
but it means you can do stuff like adrp (or whatever the riscv version is) and then complete the address in the jump instruction itself
<geist>
oh! that's good to know
<geist>
so it's always generating the worst case codegen?
<heat>
and there's a specific relaxation, R_RISCV_ALIGN, that needs support so it fails to link any code that has a R_RISCV_ALIGN relocation
<heat>
yes
<geist>
oh ugh. so for example i guess all call/ret instruction sequences are a two instruction auipc + jalr?
<geist>
(was just looking up the instructions)
<geist>
well call instructions, sicne ret is jsut a jalr to the ra register
<heat>
a part of me wants to try and figure out relaxations and see if I can add support to lld but I feel like this is a long journey
<heat>
lets see
<geist>
jal has a 20 bit offset, so most close calls can be collapsed to that
<geist>
jalr though is a 12 bit offset from register (with link register writeback)
<heat>
regular clang works because they probably default to the system's ld
<heat>
clang can still generate relaxations, it's just that lld doesn't relax anything
<geist>
all that aside, it's just an optimization, not a deal breaker
<heat>
but my target (and fuchsia's too) uses ld.lld
<geist>
and a decently modern riscv core can merge a auipc + subsequent offset
<geist>
yah i was gonna bring it up to the toolchain folks and see what they think
<heat>
geist, not a deal breaker but it's decently crap that you get worse code and you need to pass -mno-relax to every compiler invocation else it will fail to link in some R_RISCV_ALIGN
<bslsk05>
maskray.me: The dark side of RISC-V linker relaxation | MaskRay
<geist>
asking the toolchain folks internally. probably the answer is 'yeah no one has added it'
<heat>
the blog post I linked explains why it's tough to add to lld
mahmutov has quit [Ping timeout: 250 seconds]
<heat>
mold handles R_RISCV_ALIGN but no RELAX
<heat>
GNU ld (bfd) handles relaxation
<geist>
yah i think the primary riscv developers are mostly working against gcc and binutils first, so it seems to be a bit farther along
elastic_dog has joined #osdev
<vdamewood>
My mailbox is smashed.
k8yun has quit [Quit: Leaving]
k8yun has joined #osdev
<heat>
if I do anything to change a section's size isn't there a possibility that other relaxations or relocations stop being valid?
<heat>
making this effectively a loop
<Bitweasil>
vdamewood, Pi or postal service?
<vdamewood>
Bitweasil: Postal Service
<Bitweasil>
Huh.
<Bitweasil>
Do what some people I used to know did, build a brick enclosure for it.
Lugar has joined #osdev
<Clockface>
do the r9-15 registers have 16 bit "subregisters", or am i stuck with 64 bit operands using them?
<Clockface>
i dont see anything describing them as other than just 64 bit
<Clockface>
but im hopeful
<heat>
you have r9d,...
<gog>
Clockface: suffix with w to get 16 bits
<gog>
eg r9w
<Clockface>
thankss
<Clockface>
*thank you
<gog>
;)
<heat>
yeah you have r9b, w, d for the lower 8/16/32-bits
rustyy has quit [Quit: leaving]
<gog>
the only difference with the amd64 numbered registers is you don't have access to the high/low bytes of a 16-bit
<gog>
only the lowest byte
rustyy has joined #osdev
k8yun has quit [Quit: Leaving]
<Clockface>
that is fine for what i am doing
<heat>
risc architectures are all the rage in #osdev these days
<heat>
booooo x86
<Clockface>
but i like x86 :(
<heat>
reject x86, embrace unreadable assembly
<Bitweasil>
The whole "Work on the upper 8 bits of the lower 16 bits of a register" thing didn't age well... I think that was part of the Skylake hyperthreading corruption bug.
<heat>
meanwhile auipc go brrrrrrrrrrrrrrrrrrr
<Bitweasil>
heat, we like to live riscy? ;)
<Clockface>
why does assembly need to be readable???
<Clockface>
everyone writes C now, its basically just portable assembly!
<Bitweasil>
... not around here.
<Clockface>
assembly is less infuriating sometimes
<Clockface>
wasnt the 8088 a cheap version of the 8086?
<vdamewood>
I'm kind of curious. Would it make a difference if an architecture only had a 64-bit (or n-bit) ALU, but still had 8-, 16-, 32-, and 64-bit load/store instructions (or n and >n load store instructions)?
<vdamewood>
Clockface: Are we talking a userland program? The program may not even be loaded at 0:0.
<gog>
into firmware
<heat>
it still works
<Clockface>
i meant the instruction counter register
<Clockface>
ohh
<Terlisimo>
isn't IP 0 the start of code segment? so cs:ip is the actual address
<klange>
I load my programs at 1GB to keep them on their toes
<Clockface>
yeah, thank you Terlisimo
<kingoffrance>
"wasnt the 8088 a cheap version of the 8086?" follow that thread and you end up with: Tadashi Sasaki attributes the basic invention to break the calculator into four parts with ROM (4001), RAM (4002), shift registers (4003) and CPU (4004) to an unnamed woman from the Nara Women's College present at a brainstorming meeting
<kingoffrance>
unnamed woman all the way down
<heat>
Clockface, wait what's your question really?
<Clockface>
i was wondering if the program counter was from the start of physical adresses or the start of the code segment
<gog>
start of a segment. in protected mode too, even
<gog>
but most protected mode uses 0-based segments with 4GiB limits
<vdamewood>
Yeah, it's just that in protected mode every one just sets... yeah, all segments to 0.
<heat>
on an 8086/80386 it's from the start of the code segment
<heat>
on x86_64 it's from linear address 0
<gog>
yes
<gog>
because segmentation is ignored
<heat>
actually in this case it's virtual address 0
<gog>
(except in the case of FS and GS)
<gog>
also that
<heat>
linear is when you apply segmentation on top (so in x86_64 linear = virtual)
<Clockface>
x86-64 memory is weird
<Bitweasil>
Hm?
<vdamewood>
As much as I hate segmentation... I've had a chance to think about programming 8- and 16-bit processors, and having the segments was wonderful.
<Bitweasil>
No, x86-32 memory is weird.
<Bitweasil>
64-bit is just pure page tables.
<vdamewood>
Bitweasil: There's a big gap in the middle.
<Clockface>
i havent used paging yet, i guess thats why
<vdamewood>
It's easier to think of x86_64 memory as signed, 48-bit values.
<gog>
actually x86_64 memory is very sensible
<gog>
compared to previous x86
<vdamewood>
the only thing weird about it is the gap.
<gog>
and RIP-relative addressing is a godsend
<gog>
yes but the gap isn't even that weird
<gog>
and it makes more sense to have the gap then to have a ceiling
<gog>
imo
<heat>
the gap is present in every arch
<klange>
don't think of it as agap
<klange>
think of it as addresses being signed
<vdamewood>
klange: Like what I said above?
<klange>
you don't have to them of them as 48-bit values if you are thinking of them as signed
<Bitweasil>
vdamewood, the "gap" is just so you don't use the upper bits to store stuff that will later be address space.
<Bitweasil>
See the 24 to 32 bit transition in Mac.
<Bitweasil>
Lots of stuff broke when all of a sudden the upper 8 bits were being used for addressing.
<heat>
but you do use the upper bits to store stuff
<heat>
v8 for example
<Bitweasil>
Not with x86 virtual addresses, you're not. You have to explicitly filter that before you use it, unlike the ARMv8 tagging and such.
<heat>
also hwasan
<Bitweasil>
You can't just put stuff in there and ignore it like you could on some older stuff.
<Bitweasil>
32-bit address, 24 bits wired, the *hardware* ignores the upper 8 bits.
<heat>
yeah but ignoring it is more sensible IMO
<Bitweasil>
... again, not if you want to do what Intel's doing and going to... 56 bit virtual addresses?
<vdamewood>
Why is this the first I've heard of a 24- to 32-bit transition in the Mac?
<Bitweasil>
They're adding another layer of translation for it.
<Bitweasil>
idk, how old arey ou?
<vdamewood>
And when did that happen?
<Bitweasil>
Early 90s?
<Bitweasil>
The SE/30s were in the middle of it.
<vdamewood>
So before the PPC transition?
<Bitweasil>
They could run 32-bit pure, it was just a hassle to get everything running 32-bit pure.
<Bitweasil>
Yeah, this was 68k era.
<Bitweasil>
SE/30s support something insane like 128MB RAM if you do it right.
<heat>
Bitweasil, everything that stores information in virtual addresses will break regardless of the top bits being ignored
<vdamewood>
Bitweasil: Well, this looks like it's going to be 'fun' to research.
<Bitweasil>
*shrug* M'kay? I never hand-write stuff for the 68k, so I'm not as familiar with it as I probably could be.
<Bitweasil>
The 24-bit addressing to 32-bit addressing transition for Apple was a mess, and the current VM systems are designed to prevent that being the case again.
<heat>
it's just that with top bits being ignored you can do fun tagging stuff, and without ignoring bits you can't