<klange>
I also finally implemented proper floor division and Python's idea of how modulo should work on negative inputs, so that's nice
<klange>
It does seamless transition from "small" ints to "big" longs, which CPython used to in like 2.2 and whatnot, but I have good reason to keep the 'int' and 'long' types separate while Python moved to a single 'int' type: my 'int's aren't heap objects.
<klange>
I have a bunch of places I need to make C functions accept the new longs, and I still need to do some float conversion stuff that I'm afraid I don't have the libc support for in Toaru... but for basic integer arithmetic it's all working nicely, and I finally squeezed all of my int string parsing into one implementation and added support for digit separators.
<geist>
bit how does it switch to unbounded amount of size?
<geist>
without it being heap?
wowaname has quit [Remote host closed the connection]
wowaname has joined #osdev
<klange>
The VM has a 'value' type, which is a NaN-boxed entity stored in stack cells, list entries, function arguments, etc.; the values an entity can contain are either pointers to objects, or one of a handful of primitive types: doubles, 48-bit ints, bools, None, NotImplemented, some magic sentinel values used by the VM for exception handling and complex function argument passing...
<klange>
Er, the types of things a value can contain*
<geist>
ah so it switches to a pointer dynamically?
<klange>
Basically, any operation takes some set of values and produces a new one.
<klange>
So to add, you pop two values - whatever they may be - and do dynamic method dispatch to run the __add__ function for the first one with the second as an argument.
<geist>
makes sense, though seems like that'd be a little difficult to efficiently perform a long series of math operations, since it would have to reload from stack after every once right?
<geist>
yeah
<klange>
Yeah, the perils of stack-based bytecode VMs.
<klange>
So the __add__ method for small integers does simple overflow checking, and on overflow converts both arguments to bigint forms and defers to the bigint __add__.
<geist>
oh some local person is selling an IBM XT on craigslist
<geist>
they're asking too much but would be a lovely addition to the collection
<klange>
It does this naively, so for "large small ints" it will likely overeagerly defer, but that avoided having to think too hard about edge cases, or deal with the fact that I went with 48-bit ints to maximum the amount of space I get and then have to support overflow detection with 96-bit results to multiplication...
<geist>
well actually it's pretty competitive price wise to ebay right now, but those are too expensive too
<klange>
The bigint functions, meanwhile, when the reproduce a result object, will check if it fits in the small int type and produce a small int value instead - useful in the current setup so you don't end up with a value that looks like it should work in all the existing plumbing that only accepts ints.
<klange>
when they produce*
<geist>
i guess that is a degenerate case though: a series of operations that keep twiddling it back and forth bertween big and small ints
<geist>
thus wailing on the heap
<geist>
might make some sense to have some sort of hysteresis to avoid that
<klange>
Eh, they'll wail on the heap anyway, it's never in-place. I basically made the bigints immutable, not strictly in the backend, but the frontend does not offer any way to modify them.
<klange>
Language semantics I inherited from Python kinda force that.
<geist>
all hail the Crab
<klange>
All hail the ~~snake~~ teleporting schoolgirl.
<geist>
is that your language's mascot?
<dh`>
you can likely figure out statically in advance where it's worth considering shortening the values
<dh`>
(iow, mostly it isn't, so only certain kinds of downstream flows are interesting)
<klange>
Yeah, there are situations where it's clear that having longs as inputs means the output will be long, like bitwise operations, or multiplication as long as both are long, or various addition operations...
<klange>
I should say "multiplication as long as neither input is 0."
<dh`>
full range analysis is hard and likely too expensive for a compilation pass in front of an interpreter, but some simple stuff is likely to be fairly effective. I'd think
LittleFox has quit [Remote host closed the connection]
LittleFox has joined #osdev
arch-angel has joined #osdev
gxt has quit [Remote host closed the connection]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
gxt has joined #osdev
srjek has quit [Ping timeout: 244 seconds]
Goona97 has joined #osdev
mahk has joined #osdev
GalaxyNova has joined #osdev
Goona97 has quit [Quit: Leaving]
Likorn has quit [Quit: WeeChat 3.4.1]
Goona97 has joined #osdev
cstormtech has quit [Ping timeout: 255 seconds]
Goona97 has quit [Client Quit]
cstormtech has joined #osdev
cstormtech has quit [Ping timeout: 255 seconds]
cstormtech has joined #osdev
cstormtech has quit [Quit: leaving]
Ellenor is now known as Reinhilde
moon-child has joined #osdev
<moon-child>
Griwes: around?
<zid>
I'd just like to take a moment to point out that 'griwes' is unpronouncable
<zid>
you may now resume your day
<moon-child>
gry-wuz?
<moon-child>
(where 'u' is the schwa)
<geist>
actually fair point i've bene wondering how to pronouce it for years
<geist>
could be 'griv-es'
<moon-child>
hmm true
<zid>
griars? :p
<zid>
where the w is a sort of dark l
<geist>
so trying another strategy in the effort to figure out why the ryzen server is unstable: `processor.max_cstate=1`
<geist>
apparently this is a common enough thing that folks have been cargo culting that around for ryzen 3000 series stuff
<geist>
maybe they're onto something
<geist>
also makes sense why it appears to just lock up, even when idle
<geist>
actually *always* when idle, but that may not be statistically sigificant since it spents most of its time idle
<zid>
and yet when I was doomposting about people being early adopters of amd's new chips nobody would listen, and I was even doing it when 0 bioses supported virt groups
<geist>
possible.
<geist>
i mean it only shows up after running for like a week, but indeed, it does seem a little bit unstable. i'd be really sad if this fixes it.
<zid>
the solution to it crashing in low c-states though is
<zid>
MOAR VOLTS
<geist>
word.
<zid>
You're just never wrong if you answer moar volts
<\Test_User>
"how can I stop my CPU from burning? moar volts"
<\Test_User>
surely someone can find some way to make that a true statement
<geist>
just give it a short sharp shock, dig it?
bauen1 has joined #osdev
<zid>
moar volts will make the thermal throttling kick in more smoothly
heat has joined #osdev
mrkajetanp has quit [Ping timeout: 276 seconds]
mrkajetanp has joined #osdev
liz has quit [Quit: Lost terminal]
<Griwes>
zid, geist: it's how you'd spell "grievous" if it was a Polish word
<zid>
so it's a dark l, and I wins
<Griwes>
moon-child: sort of yes
<zid>
I'll take it in cash
<moon-child>
can I ask you an obscure question about gpus?
<\Test_User>
> Don't ask to ask---just ask!
<heat>
general Griwes
<moon-child>
haha
<Griwes>
heat: you've got it
<zid>
hilbert curve.
<Griwes>
moon-child: sure! But if it's very obscure there's no guarantee I'll be able to answer :p
<zid>
It's fine, I already answered for you
* moon-child
trouts zid
<moon-child>
so, I understand the scheduler has a very prominent role
<moon-child>
and also that, if a branch diverges within a threadgroup, both branches will be taken, and the result masked
<moon-child>
why not do the following instead?
<geist>
hmm, some references that "disable global C state control" in the bios is a solution to the ryzen problem
<geist>
so i'll try that next
<moon-child>
when a branch diverges, accumulate left-going branches into one buffer, and right-going branches into another
<zid>
the lbel for that option is 'moar volts' when you go look for it
<moon-child>
and once a given buffer is full enough, run a full threadgroup's worth of threads at a time, all taking a branch the same way
<mrvn>
moon-child: because you can't do that in parllel. adding to a buffer is a serial operation.
<Griwes>
Your question reveals that I'm not fully sure how the Volta+ independent thread scheduling thing works
<mrvn>
(well, not cheaply)
<moon-child>
mrvn: can do it with scan
<Griwes>
But for older arches, yeah, it's because that requires a bunch more silicon
<moon-child>
so ended up not being worth it for most workloads? makes sense
<moon-child>
volta+ does something fancier?
<mrvn>
moon-child: I would expect that by the time you have partitioned all the threads you already have computed both branches.
<Griwes>
Having it be flags where you just serially run through everything is very simple and cheap
<moon-child>
mrvn: this is why I mention the role of the scheduler. While you're partitioning threads, you can do useful work on something else
<Griwes>
Remember that at least for our gpus virtually(?) all instructions are conditional, so you can put a flag on basically anything
<Griwes>
So the same mechanism is also useful for users
<heat>
geist, I didn't buy the itanium server, for now at least
<heat>
I agree that it would give me some great street cred though
<mrvn>
moon-child: How are threads stored internally? An array of the register+state?
<moon-child>
ask Griwes, not me :P
<Griwes>
Volta+ is fancier, because you can now do cas loops within a warp and it will eventually converge instead of just hanging forever
<Griwes>
There's an amount of leeway for independent execution within a warp
elastic_dog has quit [Ping timeout: 272 seconds]
<moon-child>
how does that work?
<moon-child>
does it serialise if it notices two threads in the same threadgroup touching the same memory?
<Griwes>
Your best bets for trying to understand it is to read the whitepaper or watch Olivier Giroux's "inside volta", but I'm not sure how much of the "how" is public info
<moon-child>
ok
<moon-child>
have a link to the whitepaper?
<Griwes>
Between the warp and the memory there's a memory access coalescer that does clever stuff when there's concurrent access
<Griwes>
First google result for "nvidia volta whitepaper" is it for me :P
Matt|home has joined #osdev
<mrvn>
heat: don't you write your gpu code to not branch and only use conditionals wherever you can anyway?
<heat>
i dont write gpu code
<Griwes>
mrvn: unsure what the state is precisely; there's registers, there's lmem (local memory, which architecturally is a carveout from l1 cache I think that you spill things from registers to when necessary), but I'm sure there's more
<Griwes>
moon-child: one of the reasons why it's only Volta that learned to be more divergent is that the arch team did a *massive* amount of work to get to a formally verified memory model in the timeframes of Pascal and Volta. Pascal can do most atomic algorithms that don't do CAS loops; Volta has a proper memory model (matching that of C and C++) and finishing that gave them the power to also enable CAS loops
<moon-child>
makes sense
<moon-child>
praise boehm :P
<Griwes>
If you want to hear more on how that went, there's two CppCon talks from Olivier where he talks more about it
chibill has quit [*.net *.split]
<moon-child>
(also--formally verified, wow)
<Griwes>
Especially "the 10 year work to put std::atomic in cuda" I think is the title
<Griwes>
He goes into the details of how they've done a bunch of the verification work
<Griwes>
(it also gives me a shoutout at the end :P)
<zid>
Griwes: I'm going to need a free sample of a volta card to confirm you're not making this all up
<Griwes>
But the one where he shows how much faster building a trie is on the GPU than on the CPU
<Griwes>
Where at the end more than one person went "I think you just sold a bunch of GPUs today"
<Griwes>
lol
<zid>
I'm on.. Gp107.. pascal?
<Griwes>
Yeah
<zid>
I'd like gpus more if they weren't consumables
<zid>
gpus die faster than mech drives do by a factor of like 10
<zid>
I've got a big pile of gpus with speckles or crashes or just nothing
psykose has quit [Remote host closed the connection]
chibill has joined #osdev
<zid>
and a 1TB hdd from 2007 that's been online for 13 of those 15 years in the same timeframe :P
psykose has joined #osdev
<Griwes>
Well, I'd be afraid to keep anything of value on such a hdd :p
<moon-child>
mirroring ftw
<zid>
if it works it works, when it comes to hdds, imo
<zid>
either they've got a leak or dust in the bearing or whatever and they will die in a couple of years
<zid>
or they don't and won't
<moon-child>
zid: yea but what are you gonna do when you lose your data
<zid>
cry?
* moon-child
pets zid
<moon-child>
there, there
<zid>
It's not gone yet!
<zid>
It's mainly got steam games, github local repos and anime on it
<zid>
all of which I can replace
<zid>
My SSD is more likely to die than my hdd I think
Irvise_ has quit [Ping timeout: 252 seconds]
<zid>
Just because that has a known maximum number of writes
chibill has quit [Ping timeout: 252 seconds]
<moon-child>
ah yeah hdd is probabilistic right?
kristinam has joined #osdev
Burgundy has joined #osdev
<heat>
you need an icmp drive
<heat>
entirely probabilistic
<heat>
cheap too
<mrvn>
zid: One reason though is that disk sizes have been kind of constant lately and instead file sizes have shrunk. I used to have quater size vcd files for a TV epsisode at 350MB. That went up to 1GB for 720p. Nowadays I have 1080p x265 at 250MB.
<mrvn>
video takes up a lot less space again
<mrvn>
zid: My NVME is specced to ty after 48h of use at max speed.
<mrvn>
s/ty/die/
<mrvn>
(die == have unrecoverable errors)
<heat>
what
<heat>
thats not good
<mrvn>
It's expected to fail after 400TB of writes at 2GB/s.
<mrvn>
or 40TB? something like that.
<heat>
if you run tests/benchmarks on it for 48h it dies?
<heat>
fuck
<mrvn>
just probably.
<heat>
that's horrific
<heat>
storage people must chew through it then
<mrvn>
But it's normal. Check your own SSD or NVME.
<psykose>
400tb at 2gb/s is ~55.5 hours, checks out
<psykose>
i've seen less than 200tb
<psykose>
but yeah most people aren't actually doing that
<mrvn>
It's also suppsoed to handle 1000-10000 writes per block
<mrvn>
That would be 2EB to 20EB.
<mrvn>
maybe haldf that to account for wear leveling
<heat>
I have a warranty with 600 TBW or 5 years
<heat>
MTBF 1.5 Million Hours
<mrvn>
heat: and how long would it take to write 600TB at max speed?
<heat>
2 weeks
<mrvn>
slow. But still insane
<heat>
#SATAGANG
<mrvn>
Those failure numbers are pretty much pure fiction.
<zid>
I'd have used barely any writes on my ssd if windows didn't write 2MB/s for no reason all day every day
<mrvn>
firefox does that too
<zid>
I've written 46.2TB just from windows existing
<heat>
mrvn, pure fiction in the sense that they're better IRL?
<heat>
zid, windows moment
<psykose>
aye, the persistence store thing in firefox is constant writes
<mrvn>
heat: depends on whcih number you look at.
<psykose>
iirc you can toggle it but you then.. lose that crash backup behaviour
<mrvn>
psykose: it should onw write when there are changes
<zid>
It has 600 TBW though so I should have a while longer, plus it's overprovisioned or whatever for extra safety
<heat>
gnew slashe linuks, or as I've recently taken to call it, gnew plous linuks, would never do that
<psykose>
yes, but afaik it averages them or something? because it never goes above like 2MB/s or so, or maybe i'm forgetting
<zid>
oh 600W is the bigger model
<psykose>
either way it's the biggest disk user
<heat>
whats your SSD
<zid>
so I only get 150, how rude
<mrvn>
psykose: it just writes every N ticks.
<heat>
I have a samsung 870 evo
<psykose>
yea
<zid>
850 pro
<zid>
MGX MLC, 512MB DDR3, 2 million hours, 150TBW
<mrvn>
I've got 2 KingDian 32GB SSD drives to play with.
<heat>
I just get 1.5 million hours
<heat>
south korean engineering going backwards :(
<zid>
evo is the cheap one
<mrvn>
You know, for writing SATA drivers for my OS and such.
<heat>
YOU'RE THE CHEAP ONE
<zid>
I am cheap indeed
<heat>
there's a cheaper one btw
<mrvn>
I think the 32GB SSDs where 25E each.
<heat>
it goes like 870 -> 870 evo -> 870 pro
<heat>
something like that
<zid>
is the 870 naked made of twigs or something
<zid>
the evo is bad enough
<heat>
naw its good
chibill has joined #osdev
<heat>
solid and fast
Irvise_ has joined #osdev
<heat>
the queued trim is broken like in any other samsung ssd
<heat>
but its nice. changed my life
<psykose>
my 860 evo hard hangs everything on the system if i `fstrim` while online
<psykose>
(until i stop the fstrim or it ends)
<zid>
they're all crap compared to optane though so whatever
mahk has quit [Quit: WeeChat 3.0]
<mrvn>
psykose: you aren't supposed to send a million TRIM commands at once.
<psykose>
how does one trim an ssd then if not for fstrim
<mrvn>
psykose: allo the FS to trim naturally
<mrvn>
allow
<psykose>
sure. but without that, manually
<mrvn>
then you only do it when you can freeze the FS for a bit
<psykose>
ah
<psykose>
okay, expected then, makes sense
<heat>
without queued trim you can't queue trim commands
<mrvn>
psykose: maybe. can't think how fstrim would find all unused blocks and then trim then if it doesn't freeze the FS.
<heat>
samsung ssds are all blacklisted in the kernel because the queued trim implementation is broken
<heat>
so you probably need to stop it
<psykose>
the only reason i didn't have trim enabled fs-level is because i cargo culted some xfs docs that 'didnt recommend it' or something
<heat>
ext4 or capital punishment
<psykose>
death? at last!
<mrvn>
psykose: some SSDs don't handle many small trims well. Or the erasure block size is larger than the FS block size and trim doesn't work on FS blocks.
<heat>
btrfs and zfs are the rust of filesystems
<psykose>
maybe i should start using them then, never tried
<psykose>
mrvn: right, checks out..
<mrvn>
skip btrfs. try zfs
<mrvn>
the licensing issue is a bit iffy on Linux but otherwise it's great.
<heat>
so you can't upgrade your kernel
<heat>
10/10
<mrvn>
heat: huh? Why can't I upgrade my kernel?
<heat>
at least in arch (which I do use, btw) it's a common problem
<mrvn>
then arch is broken
<heat>
you update the kernel too quickly and the zfs package hasn't updated yet
<heat>
this is not boring debian
<heat>
exciting, bleeding edge linux distro
<heat>
versus boring stable debian
<mrvn>
then you need somone to package/port bleeding edge zfs
<psykose>
arch is not exactly the only edge distro
<heat>
but these are packaged by two different people
<psykose>
also you can just dkms zfs and it would be fine
<mrvn>
psykose: not on a bleeding edge kernel when they change some struct
gareppa has joined #osdev
<heat>
doesn't really exist
<psykose>
for dkms? yeah, but that would go for the 'normal' zfs packaging too, it would be momentarily uncompilable
<mrvn>
does arch only have pre-built zfs modules?
<heat>
apparently
<heat>
there's something on the AUR but it doesn't seem to work very well
<heat>
also, AUR
<mrvn>
that's so stoneage
<heat>
what kernel are you on again?
<mrvn>
bronze age
<psykose>
appears to be 5.18.7
<psykose>
(without zfs)
<heat>
Linux PC-PEDRO-ARCH 5.18.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 16 Jun 2022 20:40:45 +0000 x86_64 GNU/Linux
<mrvn>
I tend to update kernels when I reboot and not reboot when I update kernels.
<heat>
linux 5.18.7.arch1-1
<klange>
> Linux luka 5.4.0-113-generic
<klange>
heh
<zid>
we need signed uptimes because of VMs ruining it
<j`ey>
klange: same: 5.4.0-99-generic
<klange>
I accidentally closed the shell on the serial console on my rpi400 so I can't `uptime` on it anymore but closing the shell did launch the gui and the clock is still happily ticking along so that's nice
<heat>
Linux raspberrypi 5.15.36-1-MANJARO-ARM-RPI
<heat>
up for a month
<heat>
sheesh
<j`ey>
Linux 5.19.0-rc4-next-20220628 #1499
<heat>
chad kernel developer vs virgin linux users
<heat>
psykose, do you know if alpine supports the rpi zero 2w yet?
<psykose>
always has bar a missing entry in the boot thing.. and now the missing entry is there
<psykose>
so i guess yes
<psykose>
i think the wifi won't work on 3.16 but does on edge
<heat>
i really want it but I ran into firmware issues
leitao has joined #osdev
<psykose>
could be either of those things then, and both should work on edge
<psykose>
i should backport the firmware to 3.16, sec
<heat>
nice
<heat>
is alpine edge relatively stable?
<psykose>
ime yeah
<psykose>
but i'm incredibly biased there for obvious reasons
<psykose>
(i see every change)
<heat>
lol
<heat>
then you have a more informed opinion that anyone else
<psykose>
backported- so it should be part of the 3.16.1 rpi image when that release happens, and for now you would need to make your own image for wifi to work on that i guess. aside from that i forgot how fiddly the pi stuff is, i just use a normal ethernet rpi4
Dyskos has joined #osdev
mahk has joined #osdev
<mrvn>
I'm always happy when my RPi has 2^32 microsecond uptime and the 32bit timer overflows.
<mrvn>
Hard to test the 64bit counter for the timer since it always starts at 0 on boot.
Ram-Z has quit [Ping timeout: 272 seconds]
vdamewood has joined #osdev
the_lanetly_052 has joined #osdev
Dyskos has quit [Ping timeout: 244 seconds]
gog` has quit [Quit: byee]
gildasio has joined #osdev
<clever>
mrvn: that overflow was once a bug for me, the timer compare was enabled, but the compare was never set, so it defaulted to 0
<clever>
2^32 microseconds after booting, i got an unexpected interrupt, and at the time, any interrupt was fatal
<mrvn>
my timer wakes up every 2^32 microseconds too even if everything sleeps.
Dyskos has joined #osdev
Dyskos has quit [Client Quit]
Ram-Z has joined #osdev
stephe has joined #osdev
Burgundy has left #osdev [#osdev]
<heat>
thats The Way to do timers
Dyskos has joined #osdev
Ram-Z has quit [Remote host closed the connection]
Ram-Z has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<heat>
is there an itanium emulator anywhere?
<psykose>
i think intel sells some physical ones you attach to a motherboard
<psykose>
i was supposed to anyway, i had just forgotten for a few weeks
<psykose>
it should also (already) work- you could just manually copy in the needed fw into the unpacked .tar.gz onto storage and go from there, i suppose. more effort than waiting for the actual image in $whenever
Likorn has joined #osdev
xenos1984 has quit [Quit: Leaving.]
leitao has joined #osdev
<mrvn>
Has anyone tried to use SIMD to sort a small array?
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Bonstra has quit [Quit: Pouf c'est tout !]
Likorn has quit [Quit: WeeChat 3.4.1]
Bonstra has joined #osdev
ethrl has joined #osdev
elastic_dog has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
sbalmos has quit [Quit: WeeChat 3.5]
sbalmos has joined #osdev
X-Scale` has joined #osdev
k8yun has joined #osdev
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
gog has joined #osdev
dennis95 has quit [Quit: Leaving]
k8yun has quit [Quit: Leaving]
<geist>
heat: heh i planted the ia64 idea in your head huh
<geist>
but yeah qemu doesn't do itanium. that's honestly the main reason i haven't futzed with it
<geist>
there are probably some emulators out there though
<geist>
the ski thing looks interesting though
<geist>
looksl ike the source is so old it wont compile easily with autoconf or whatnot
<geist>
has't been touched since 2008
Likorn has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
<bslsk05>
'AC/DC - Thunderstruck (Official Video)' by acdcVEVO (00:04:53)
<mjg_>
is playing with itanium considered doing it osdev the hard way?
<mjg_>
(like doing x86 would be considered "easy")
<mrvn>
how is x86 easy?
<mjg_>
see quotes
<mrvn>
itamium is easy. nobody will report bugs
<mjg_>
"easy" as in there is tons of resources out there
<psykose>
it has an 'x' in it, which makes it advanced and hard.
<PapaFrog>
Amd64 is harder because it has AMD in it.
<mrvn>
aarch64 is harder, more letters
<zid>
but it's easy because it has 64 in it, which means mario can help you
<Ermine>
Where '128' arches?
<zid>
we already have 512
<Ermine>
this number should be in the name
<Ermine>
Aarch512
<mrvn>
128 and 512 is bad, you need another level of 74182 for the adder every factor of 4.
<ddevault>
for 64-bit PCI BAR registers
<ddevault>
are they little endian, such that the first register is the most significant?
<ddevault>
yes
<ddevault>
thanks
SGautam has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
srjek has joined #osdev
<mrvn>
are they 2 32bit registers or one 64bit register?
<ddevault>
you can distinguish between these by checking bits 2-1 of the first BAR register, iiuc
<heat>
geist, it's a really cool idea
<heat>
tons of street cred
<heat>
and you get the undying respect of intel engineers
<heat>
"oh that itanium crap was horrible" "yeah well I kinda liked it"
<heat>
on the downside, you need to get one
<geist>
yah the paging and syscall mechanism and whatot is especially weird
<mrvn>
but it have us C++ exceptions. they must have done something right
<geist>
like they threw all the general outstanding research papers at those problems
<geist>
i always assume a lot of the itanium originated exceptin/abi stuff that we love now was just because it was the first new interesting arch at the time that that stuff was getting standardized
<geist>
so it ended up bearing the name
<mrvn>
it's easy to invent some new ABI when you have no code to break.
<geist>
right
<ddevault>
I am confuse
<heat>
hello confuse, I'm heat
<clever>
27.44c(81.39f)
<clever>
heat: but how heat are you!?
<heat>
22C right now
<mrvn>
clever: that's cold.
<ddevault>
my PCI driver does not return results which are consistent with linux
<mrvn>
Hypothermia (hi-poe-THUR-me-uh) occurs as your body temperature falls below 95 F (35 C).
<clever>
mrvn: for me, thats hot enough that i'm opening windows that havent been opened in months
<heat>
ddevault, what do you mean
<mrvn>
that only helps if it's colder outside.
<ddevault>
my PCI bus scanner does not return results which entirely make sense, heat
<bslsk05>
www.gnu.org: Various Licenses and Comments about Them - GNU Project - Free Software Foundation
<mrvn>
ddevault: then your file must be only NCSA too
<ddevault>
sorry, that's not how it works
<heat>
Often the only feasible way to resolve this situation is re-licensing of all participating software parts. For successful relicensing the agreement of all involved copyright holders, typically the developers, to a changed license is required.
<heat>
per le wikipedia
<ddevault>
this was not relicensed in that sense
<heat>
"For instance, Mozilla assumed an author coverage of 95% to be sufficient."
<mrvn>
ddevault: yes it is. You can use it but you can't change the license.
<ddevault>
the original license *and* the GPL both apply
<geist>
heat: wasm drivers on itanium
<geist>
DOUBLE WHAMMY
<ddevault>
relicensing is only when the original license is being removed
<heat>
ohh fuck yeah
<heat>
talk dirty to me
<mrvn>
ddevault: so I can take your code and add my "pay-me" license where all previous authors have to pay be 100$?
<ddevault>
no
<ddevault>
but you can, I guess, sell someone's code back to them
<ddevault>
if they're dumb enough to pay
<mrvn>
ddevault: but that's what you just did. add a random license.
<ddevault>
listen, man
<ddevault>
this is not how licensing works
<ddevault>
even linux, a famously GPL'd project, incorporates a bunch of non-GPL works
<ddevault>
the whole KMS subsystem is MIT, for instance, which is why it could be ported to BSD
<mrvn>
ddevault: sure, but they don't change the license
<ddevault>
and neither did I
<ddevault>
the original is NCSA, and my changes are GPL
<mrvn>
you did, you claim it's GPL
<ddevault>
no, I don't
<ddevault>
god
<mrvn>
And your changes are NCSA, says so right in the file
<ddevault>
let me put it this way
<ddevault>
as someone who intimately understands free software licensing in great detail
<mrvn>
There is no one work about the NCSA applying to the original and GPL to the changes or anythingö
<ddevault>
I can assure you that this is above board and I am not interested in arguing with you about it
<heat>
geist, if I suggest an itanium port in the fuchsia discord will people take me seriously
<mrvn>
ddevault: did you study law?
<ddevault>
did you?
nj0rd has quit [Quit: WeeChat 3.5]
<mrvn>
So apparently not.
<ddevault>
I'm pointing out that you have no higher claim to understanding the law than I
nj0rd has joined #osdev
<heat>
but you said you "intimately understand free software licensing in great detail"
<mrvn>
and give legaly advice
<mrvn>
"I can assure you" that could get you into legal trouble.
<heat>
I think in this IRC chat we all ANAL
<geist>
heh yeah i dont even bother tow ade into these
<geist>
anyway, building ski, i just needed libtool-bin, etc
<heat>
does it work
<heat>
are you porting lk to itanium
<mrvn>
The only person who can really say anything is klange
wowaname has quit [Ping timeout: 268 seconds]
<geist>
ah, no failed to compile. using ustat.h which no longer exists
<geist>
so will require some work
<geist>
will fiddle with later
vdamewood has joined #osdev
ethrl has joined #osdev
<heat>
ddevault, btw regarding your code, it looks fine
<heat>
i would see the llvm bytecode/final disasm so there's no surprises when it comes to hare's codegen
<heat>
but it looks correct
koolazer has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
night has quit [*.net *.split]
PapaFrog has quit [*.net *.split]
zid has quit [*.net *.split]
ZipCPU has quit [*.net *.split]
\Test_User has quit [*.net *.split]
bliminse has quit [*.net *.split]
mavhq has quit [*.net *.split]
LambdaComplex has quit [*.net *.split]
nether has quit [*.net *.split]
HeTo has quit [*.net *.split]
MrBonkers has quit [*.net *.split]
hl has quit [*.net *.split]
citrons has quit [*.net *.split]
chibill has quit [*.net *.split]
Irvise_ has quit [*.net *.split]
rorx has quit [*.net *.split]
Serpent7776 has quit [*.net *.split]
edr has quit [*.net *.split]
brynet has quit [*.net *.split]
ebb has quit [*.net *.split]
ecs has quit [*.net *.split]
raggi has quit [*.net *.split]
sauce has quit [*.net *.split]
milesrout has quit [*.net *.split]
sm2n has quit [*.net *.split]
ddevault has quit [*.net *.split]
exec64 has quit [*.net *.split]
gjnoonan has quit [*.net *.split]
tom5760 has quit [*.net *.split]
alethkit has quit [*.net *.split]
patwid has quit [*.net *.split]
jleightcap has quit [*.net *.split]
eck has quit [*.net *.split]
dh` has quit [*.net *.split]
dzwdz has quit [*.net *.split]
acidx has quit [*.net *.split]
qookie has quit [*.net *.split]
Arsen has quit [*.net *.split]
wereii has quit [*.net *.split]
graphitemaster has quit [*.net *.split]
shikhin has quit [*.net *.split]
remexre has quit [*.net *.split]
Griwes has quit [*.net *.split]
LittleFox has quit [*.net *.split]
arch-angel has quit [*.net *.split]
les has quit [*.net *.split]
GreaseMonkey has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
cultpony has quit [*.net *.split]
tomaw has quit [*.net *.split]
Starfoxxes has quit [*.net *.split]
kazinsal has quit [*.net *.split]
kaichiuchi has quit [*.net *.split]
pounce has quit [*.net *.split]
lg has quit [*.net *.split]
nickster has quit [*.net *.split]
Ameisen has quit [*.net *.split]
kori has quit [*.net *.split]
buffet has quit [*.net *.split]
dequbed has quit [*.net *.split]
moon-child has quit [*.net *.split]
particleflux has quit [*.net *.split]
Bitweasil has quit [*.net *.split]
colona has quit [*.net *.split]
dormito has quit [*.net *.split]
ozarker has quit [*.net *.split]
Affliction has quit [*.net *.split]
duckworld has quit [*.net *.split]
kingoffrance has quit [*.net *.split]
<heat>
split net!
<heat>
actually, erm
<heat>
has any itanium ever run javascript or wasm
<sbalmos>
sort of reminds me, vaguely, of LLVM's internal IL
sympt has joined #osdev
<heat>
he 64-bit virtual address space is divided into eight 2^61 byte virtual regions.
<heat>
holy fucking shit what
liz has joined #osdev
<heat>
The region is selected by the upper 3-bits of the virtual address. Associated with each
<heat>
number) for the region. Eight out of the possible 2 24 virtual address spaces are concurrently
<heat>
bits of a large 85-bit global address space for a single address space model, or as a unique ID for a
<heat>
accessible via the 8 region registers. The region identifier can be considered the high order address
<heat>
virtual region is a region register that specifies a 24-bit region identifier (unique address space
<heat>
multiple address space model.
<heat>
this is so bonkers
<heat>
they should've made virtual regions have GUIDs
<geist>
but it also means you get iirc a full 64bit address space. proper
<geist>
far as i know the only arch that promises it. maybe high end POWERs
<geist>
the 85 bit global thing is a bit hand wavy, that's basically saying 'all of the ASIDs available technically add up to a huge amount'
<geist>
POWER/PPC also claims the same thing
<geist>
though in this case it says it depends on howy ou cosider it
<ddevault>
I'm a moron, these PCI numbers *do* match between linux and my kernel
<geist>
where the itanium mmu gets really strange is it has the two different modes: one where there's IIRC a huge page table, kinda power/ppc style, i think
<ddevault>
still, I found out the real reason my I/O ports were wrong, and removed the hack comment
<geist>
and another one where the page table itself is virtual, which is a huge brain teaser
<sbalmos>
wait wut?
<heat>
geist, isn't it 2^61?
<geist>
though the virtual page table is less of a brain teaser once i worked with VAX, which actually has basically the same thing, just on a much smaller scale
<heat>
why did they subdivide the 64-bit address space into 8 smaller address spaces
<geist>
possibly so their TLBs only have to match against 61 bits or so
<geist>
and/or to make the virtual page tables easier to manage
<heat>
or am I not thinking this through like a True Intel(R) Itanium(R) Developer(tm)(R)(c)
<geist>
yeah
<heat>
so wheres the 64-bit address space?
<geist>
anyway, gotta go do some meetings. have fun reading it!
<heat>
aw
<geist>
also wait till you get to the `epc` instruction. it's also crazy and unique as far as i can tell
vdamewood is now known as 030AAFINU
<heat>
so the top 3 bits index into 8 virtual regions, those regions function like a literal region of address space, you can coalesce them and each virtual region has its own translation policy and page size
<heat>
page sizes ranging from 4KB to 256MB
<geist>
or disable region. possibly set per region permissions, etc. it's kinda like instead of having a single cr3 or a dual TTBR0/TTBR1 you have 8 of them. you can use them as yo see fit
<heat>
each region then has an ASID
<heat>
ok it makes less sense
<geist>
maybe you give a process 7:1 or 1:7 or 1:....:1, up to you
<heat>
its explained in such a bullshit way
<heat>
"85-bit global address space"
<geist>
pretty flexible too: you could for example put all your shared libs across all processes in one of them
<geist>
and get maximum TLB usage there
<geist>
since it would get its own dedicated ASID
<heat>
oh crap
<heat>
there are no page tables
<mrvn>
there is no spoon
<heat>
there is no spoon, just fork()
<heat>
oh wow you can insert entries into the tlb manually
<heat>
this is cool
<heat>
probably useless, but cool
<heat>
(well, in this case, may be useful since we don't have page tables)
<heat>
the VHPT is optional
<heat>
somehow, this makes sense
<heat>
hardware can avoid taking penalties walking page tables if the kernel hints it mappings through the VHPT
<heat>
so you get a 64-bit address space that's relatively fast
<heat>
good idea
030AAFINU has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<heat>
that translation cache thing is also cool
<heat>
erm, translation register I mean
<heat>
"Intel® Itanium ®" my satire was entirely correct lol
<heat>
there's a probe instruction that checks permissions for virtual addresses
<heat>
i guess this was very much pre-aslr lol
<heat>
pkeys also got ripped straight from itanium huh
<heat>
yo dawg, I heard you like layers and arrows
wand has joined #osdev
<sbalmos>
oof
<gamozo>
oof
<heat>
the firmware side of things looks remarkably similar to x86 UEFI
<sbalmos>
that's what I figured it was an early version of
<klys>
claiming to have a corner on "OS Boot Selection" at the EFI layer is perhaps unreasonable...aand perhaps it would be good to start using kexec() with a boot menu for EFI systems.
SGautam has quit [Quit: Connection closed for inactivity]
<heat>
some itanium chipsets could support IA32 and itanium
<heat>
like, native IA32
<geist>
yep, itanium 1 actually ran ia32 directly, though slowly
<Ermine>
one of reasons of its failure on the market
Dyskos has quit [Quit: Leaving]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<heat>
geist, yes. but I mean real IA32
\Test_User has joined #osdev
<geist>
REAL IA32
<geist>
but you can see how EFI morphed into UEFI
<heat>
I want a dual socket IA64/IA32 setup
<heat>
oh, very clearly
<heat>
they even had a FIT, 16MB flash sizes
<heat>
two entry points! one for IA32 (the classic reset vector) and a PALE_RESET for itanium
<geist>
yah i was reading on wikipedia the other day that they were planning in the mid 2000s to have itanium ia64 and xeon ia32 use the same socket so you could put one or the other in the same machine
<geist>
it never came to fruition apparently. the specific xeon project was cancelled, so itanium ended up using its own sockt for the rest of its life
<moon-child>
cool
<gamozo>
Will the real IA32 please stand up
<mrvn>
heat: was there ever a itanium with full IA32 support? Afaik it only had hardware support for a software emulation. So a mixed solution.
<heat>
from reading the manual, it seems so?
<heat>
seems like it would branch from itanium to ia32 or itanium in the firmware
<geist>
no it did. original itanium ran ia32 directly
<geist>
it just ran it very slowly
<heat>
aha
<heat>
so it didn't run it, it walked it
<mrvn>
why is there no std::hash<std::tuple> or tie or something for compound types in c++20? :(
<heat>
shit no one liked my crap joke
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<heat>
sometimes life is like that huh
ethrl has quit [Quit: WeeChat 3.4.1]
<gamozo>
Tough crowd
<heat>
that's what intel said after releasing itanium
Burgundy has quit [Ping timeout: 272 seconds]
<geist>
eeeyooo
<geist>
that's pretty saucy
<geist>
not unlike HP
<heat>
geist, it just hit me
<heat>
since everything is supposed to be done in parallel bundles
<mrvn>
heat: next time: duck
<heat>
does it mean that it's pretty hard to jump in between two bundles?
<geist>
you dont. you can only jump to 128 bit instruction bundles
<heat>
or is this a stupid question?
<geist>
iirc the up to 3 instructions in a bundle are intrinsically run in paralle
<heat>
the bundle itself is run in parallel? or is each bundle run in parallel?
<geist>
bundle itself. i think the rules are that within a bundle two instructions cant depend on each other
<geist>
or at least can't have the output of one feed into the input of the other
<mrvn>
it's like normal CPUs decoding multiple opcodes in a single cycle. Except hardcoded to a bundle.
<geist>
yah
<heat>
geist, and I guess bundles can depend on each other?
<geist>
yes, i think so. though later itaniums of course ran multiple bundles in parallel
<geist>
also means if the compiler isn't very good at scheduling it has to insert a lot of nops to complete a bundle
<mrvn>
and yeah, no dependencies. All the ordering and dependency logic is in the compiler.
<heat>
yes, but like
<mrvn>
and back then compilers sucked at it
<heat>
a bundle needs to be able to explicitly say "I depend on that bundle"
<geist>
since it shows a real program as dissassembled, showing how the bundles are laid out
<geist>
*within* a bundle the up to 3 instructions dont dep on each other, but between bundles i think it's fairly normal rules where the cpu will figure it out
<geist>
the MMI and whatnot stuff is also showing the bundle layout (memory memory integer)
<mrvn>
don't bundles finish in a cycle?
<geist>
not sure it's guaranteed to that point. the architectural model is what the programmer sees
<geist>
what the hardware can do with it is up to the implementation
<heat>
are individual bundles executing in parallel just retired one by one like x86 would do?
<geist>
i think so? i dunno honestly
<geist>
alls i can say is what i thnk the architectural model is. i dunno what real implementations do
<mrvn>
.oO(crash)
<heat>
and I guess that the CPU can only be interrupted after finishing a bundle
<geist>
possibly? good question
<heat>
an instruction pointer in the middle of it would make no sense
<heat>
unless the CPU itself deals with it
<geist>
what i also dont completely understand is the ;; part too
<geist>
i used o think it was just an assembly file side thing to hint to the assembler that however it wants to assemble the bundles it has to bundle that way
<geist>
but te dissasembler seems to be able to recreate it
<geist>
it's possible the ;; is actually a bit in the bundle that says 'this is a sync point that things after it must occur after'
<geist>
i see one instance in that disassembly that sets a reg and then uses it afterwards within the same bundle but has a ;; between it
<geist>
ah i see. all instructions between either a branch or a ;; are explicitly defined as being parallelizable
<geist>
the assembler can then package it up as it sees fit
<heat>
you send a pastebin lol
<heat>
sent*
<heat>
I'm going to have a kernel/arch/Intel® Itanium®
<heat>
it's just the proper naming
<mrvn>
it's not a good name unless it has emojies
<geist>
yeah irccloud does the pastebin if you copy paste >=3 lines
<heat>
Every memory load and store in the Itanium architecture has a 2-bit cache hint field in which the
<heat>
compiler encodes its prediction of the spatial and/or temporal locality of the memory area being
<heat>
accessed.
<heat>
lol
<mrvn>
I wonder why CPUs with accumulator (kind of) have died out. Wouldn't it save bits if you could chain opcodes so the result of one is input to the next? Maybe 3 bits to say how many opcodes to go back and use as input.
<mrvn>
The CPU does register renaming internally anyway so no need to use a external name for it, just refer to it by offset.
<clever>
the way i can see a hw accumulator helping, is if your doing accumulator += foo, in multiple opcodes
<clever>
and it can pipeline the += part, and not care about the sum right away
<mrvn>
clever: that would be a traditional acc
<mrvn>
But you could write: add %x0, %x1; sub %x0, %x1; mul %-1, %-2
<mrvn>
st %-1, mem
<mrvn>
would make register dependencies between opcodes obvious too.