dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
gog has quit [Quit: byee]
Ikkepop has quit [Quit: Leaving]
<dh`>
where in 2008 did you get a machine without transient execution vulnerabilities?
wxwisiasdf has quit [Quit: Lost terminal]
<zid>
and even then, no vulns tha people *care* about
<zid>
nobody's going hunting on a 2008 atom to see if it can be trivially sidechanneled, doesn't give good clicks on their portfolio blog :p
<epony>
it's just a bonus of reusing an improved older micro-arch
<epony>
the point made was, other vendors (except focking Arm) make ULV CPU designs too, and they can be just a lot better, a lot earlier in time, compatible, lower power usage and.. have applications and get work done, without being stupidly naive over "cleaner architecture online argument wankatude"
<epony>
no such thing as "clean" and "better" archicture.. there are successful and compatible, and failed and incompatible designs
<epony>
that's pure online rubber stamping of learned marketing leaflets
<epony>
the ones that sell highly overpriced incompatible and largely defective same thing in lower yield, lower efficiency and seriously shorter options of programming and supporting your own computation
<dh`>
2008 isn't anywhere near old enough even for a then-old microarchitecture
<dh`>
but whatever, enjoy the false sense of security
<epony>
again, not about security
<epony>
it's about "in no way the argument of clean and efficient architecture" applies to one and not another same technology competing microprocessors
<epony>
after all these are shorter and smaller product runs that live on "device specific" processors
<clever>
EL3 is the highest priv level, its always in secure mode
<clever>
EL2 runs the hypervisor
<clever>
EL1 is your kernels
<clever>
and EL0 is userland
<clever>
you drop to a lower level by putting some values into 2 registers, the saved state and exception link register, and run "eret"
<clever>
either you restore the values you had upon entering an exception handler, or you make some up if its the first time entering that level for a given guest/proc
<clever>
and you can skip levels, so you could eret from EL3 to EL1, and just run a kernel without a hypervisor
<epony>
don't know where and why people come up with the "this arch" is bad, but "the one" that they have as a replacement runs small batches with largely diverse changes would be "clean" as it's.. unclean as inconsistency, support and compability as can be
<clever>
or even EL3->EL0, if you happened to interrupt a userland proc
<epony>
a most unclean would be a never compatible with previous generations discarding all software and requiring new tooling and application designs
<clever>
armv8 does have a large number of changes that i would deem as improvements, relative to armv7
<clever>
like all of those modes you mentioned being ditched, and co-processor registers being cleaned up
<epony>
that's good, but the arch itself is.. many arches under same "branding" and different releases ;-) technically
<clever>
yeah, an armv8 core can optionally implement armv7 still, at a mix of EL's
<epony>
and there are many implementers which can have extensions or changes or combinations, so it becomes a product unique targets most of the time
<clever>
some cores only support armv7 at EL0, which is the simplest layer, all of the co-processor and cpu-mode junk is gone
<epony>
so then these become in-house well understood HW and SW combination (models) but the world gets the "runtime" to program
<clever>
where it emulating things like FIQ, IRQ, undefined, and supervisor, within EL1
<clever>
and monitor mode maps over EL3
<clever>
a mix of the graphs i linked is also possible, where you have a 32bit EL1 but a 64bit EL2/EL3
<clever>
but there is also an extra rule (kinda backwards from x86), a lower level must be at the same or smaller bit width
<clever>
so if EL2 is 32bit, then EL1/EL0 must also be 32bit
<clever>
while if EL2 is 64bit, EL1/EL0 can be either 64 or 32
<clever>
but if EL1 is 32bit, then EL0 must be 32bit
<epony>
in my opinion, it's just a different model of reusable CPU core modules provided to the compact and embedded computing device producers, because they need parts of the functionality of a larger CPU that has these "bundled in" and "backwards compatible"
<clever>
so once the cpu is in a 32bit mode, its functionally identical to a 32bit only cpu, and only a higher power (an EL with a bigger number) can restore those 64bit functions, or even expose that they exist at all
rurtty has quit [Quit: Leaving]
<epony>
those mixes and combinations seem nice, but are complex to program
<clever>
and also complex to support in silicon
<clever>
which is why some vendors opt to only allow 32bit in EL0 and nothing else, that makes the chip far simpler
<epony>
so the tools have to be more elaborate to provide these as compiler targets etc
heat_ has joined #osdev
<clever>
some vendors just ditch 32bit entirely, which is a valid option
<clever>
for gcc, its managed as just 2 entirely seperate targets, 32bit arm, and 64bit arm
heat has quit [Ping timeout: 250 seconds]
<clever>
but 32bit arm, also has arm and thumb, another layer of complications!
<epony>
yep probably that is their prefered path because the devices are short lifespan e.g. 2 years
<epony>
(as in batches produced)
<clever>
in arm mode (both 32bit and 64bit), all opcodes are 32bit long and 32bit aligned
<clever>
but in thumb mode (32bit only), opcodes are instead 16bit long and 16bit aligned
<epony>
note, desktop and server CPUs are short batches too, only a couple of years, but the volume and the sold units to board assemblies makers are.. a lot bigger in the "all-in-one" desktop/server processor series
<clever>
some cores like the cortex-m0+ are also thumb only
<epony>
so it's not entirely out of the question, that even same model devices have different CPUs even on same reseller and same consumer product versions
<clever>
that has occured with the rpi 2 as well, they replaced an armv7 soc with an armv8 soc running in v7 mode
<clever>
other then some kernel level registers differing, its largely identical
<epony>
in the mobile space, and between models of the same maker, there can be differences that would make the application programmers' job running natively a breaking / abandon project completely (check out what happened to Itanium processors despite the big ambitious designs and capabilities)
<clever>
other then extensions like crypto or crc, all armv8 cores should be functionally identical at the userland level
<epony>
in the mobile space, it's the norm.. to have even different Arm-implementers chip in adjacent models, the compilers get adjusted in house and the aplpications run in a VM
<clever>
and you should be able to run a userland program on any armv8 core without having to care about the differences
carbonfiber has quit [Quit: Connection closed for inactivity]
<epony>
also, when we look at things at the machine opcode, nothing can be "elegant" or "ugly", it's just machine opcodes, operands and processor and address modes
<epony>
so I really do not even for a second accept the notion of "bad" vs "good" architecture, it's just a different use case and design requirements
xenos1984 has quit [Read error: Connection reset by peer]
<epony>
then when we compare the extended set of instructions combined to get a comparable desktop / server or general puprose CPU.. they would be quite similar with peculiarities of each platform / arch, but not "good" and "bad" ;-) just their historic and current specifics
<clever>
epony: but there are binary level things that i would call good or bad, fixed width opcodes i think are good
<bslsk05>
en.wikipedia.org: Devicetree - Wikipedia
<clever>
it makes the oopcode decoder far simpler
<epony>
yeah, that's the premise of RISC
<clever>
i dont want to even imagine how i would make an x86 decoder
<clever>
ive been developing replacement firmware for the rpi, and it does a number of things weirdly
<clever>
much like the amd PSP and intel ME, there is a secondary procesor, that starts before the arm core, does dram init, and initializes the system before the arm turns on
<clever>
and that secondary processor is basically the master of the system, and can put the arm in a walled off jail
<bslsk05>
en.wikipedia.org: Multi-chip module - Wikipedia
<clever>
the bcm2836/pi2 has a quad-core armv7 (cortex-a7) and 2 VPU cores
<epony>
so the differences are shrinking, it's not entirely impossible that later processors might have multiple ISA capabilities
<clever>
bcm2837/pi3/pi02, quad core armv8 (cortex-a53) and 2 VPU
<clever>
bcm2711/pi4/pi400, quad core armv8, cortex-a72, and 2 VPU
<epony>
so the RISC / CISC and hybrid ISA would be a matter of reconfiguring the CPU frontend decoders (and common universal backend for the CPU logic blocks)
<clever>
the pi02 is the only thing i would call "multi chip", everything else is all on the same die/chip
<clever>
and the pi02 is only multi-chip, in that you have the soc wire-bonded directly to a dram chip
<clever>
the arm+vpu are still in the same die
<epony>
the future is not set in "stone" (lithos, stone, lithography) like the past
<clever>
and on the subject of multiple ISA's in a single cpu...
<epony>
I like the fact that there is programmability in embedded operating system running on processor cores..
<clever>
this computer was made entirely with basic logic gates and some PAL's
<clever>
it uses a microcode rom to decode the opcodes, and could run other simple ISA's (as long as it has an 8bit opcode) with only minor changes
<clever>
as long as it has enough registers, the microcode rom could support multiple ISA's at once, and switch dynamically at runtime
<epony>
that's probably useful for prototyping RISC ISAs ;-)
<clever>
ive also heard, that modern cpu's, have more registers then the api exposes
<clever>
and its dynamically doing register renaming at runtime
<epony>
yes and the internal implementation is risc-like
<clever>
and with out of order execution, it can have 2 instances of the same register at once, for different points in time
<epony>
that's completely comprehensible
<clever>
for the BMOW1, the microcode rom just outputs a giant bool array, that enables buffer gates between every register and bus
<clever>
so you might let the A register onto the left bus, and the T register onto the right bus, to feed the ALU, and store that result into X
<clever>
but when you start doing out of order execution and register renaming, you need to track the state of every opcode in the pipeline, what register is where, and pending transfers
<clever>
and then you also have another layer of complications when you have dual-issue cpu cores
<epony>
so.. as demonstrated, the RISC is expanding to a sets of instructions approaching the CISC, just different opcode and operand numbers
<clever>
the VPU for example, is dual-issue on the scalar side, and single-issue on the vector side
xenos1984 has joined #osdev
<clever>
from my benchmarking, ive found that if you run a single vector opcode, the cpu does not wait for it to complete
<clever>
so you could run a costly vector opcode, and then go off and run ~100 scalar opcodes, while you wait for the vector op to finish
<epony>
and the CISC is inernally non-specific and non-exposed as designs but using RISC like functional blocks for various processor units
<clever>
and the only harm, is that if you run a 2nd vector opcode too early, it stalls waiting for the 1st to finish
<epony>
can't accept someone chastising and proclaiming one or the other models of processor designs (and then there are memory data and instruction architecture differences too) good or bad or horrible and marvellous ;-) it's quite similar and quiet hybrid in modern times.. not competing on different vendors licensing their own processor lines and selling the entire product only any more
<clever>
if i was to implement a core like the VPU, i would have a "is waiting on vector core" flag on certain registers, and attempts to read them would stall until the vector core completes, and also a similar "waiting for scalar core" flag on scalar regisers, and then attempt to issue 2 opcodes in the same clock, if all of the inputs are ready
<clever>
then the pipeline would decode the opcodes, and if the inputs are all ready, execute them
smach has joined #osdev
<epony>
well, the fetch and data and instruction operations in static memory on processor caches is in the order of single to at most a couple of cycles that are in the picosecond range
<epony>
the same thing from dynamic memory on the same system outside the processor is in the order of a 2-3 orders of magnitude
<clever>
ive also measured the vector load opcodes, and for any vector load, there is a constant 11 cycle startup time, when running loads back2back
<clever>
plus an additional 1 clock per 256bits transfered
<clever>
but it can move up to 4096 bytes in one shot
<epony>
so it makes sense to have wider processor logic paths, concurrency internally, deep prefetching and long queues and decoder targeting optimisations
<clever>
so a vector load can take between 13 and 139 clocks, depending on the amount of data being loaded
<clever>
assuming 100% L1 hit rate
<clever>
i assume that 11 clock cycle overhead, is to get thru all of the pipeline stages, and L1 cache layers
<epony>
yeah, that's the essence of "paging", the chunks of data you can get from RAM with block reads and work with that on processor
<clever>
but once that 11 cycles is up, the entire pipeline is primed
<epony>
that's why there is segmentation and address modes
<clever>
and its able to move 256 bits on every clock
<clever>
and i assume each stage in the pipeline has a different 256 bit chunk of the answer, all lined up
<epony>
the things people hate most from school years, are about all architectures, they just were not in school for the newer ones they think are the 'greatest"
<epony>
so this model of computation (fetching blocks) of data is inevitable, that's how burst and efficiency are achieved
<clever>
yeah, this is also why larger batch sizes are better
<dh`>
are we *still* having this stupid argument?
<clever>
because it can load 512 bits of data, in 13 clock cycles, for an average of 39 bits/clock
<epony>
and packing data that would be running on sustained CPU throughput ;-)
<clever>
or it can load 32768 bits in 139 clocks, for an average of 235 bits/clock
<clever>
~6x faster, by using the max block size
<epony>
if you ask me, there is no argument, just a false sense of "fundamental differences" in ISAs tha are similar model of operation, implementation and machine architecture.. except in special cases
<epony>
but the "years" apart between processor designs an processes used and the transistor density and data throughput is there ;-)
<epony>
so the factors become more economic, rather than "programming" the hardware specifics, when they are typically "comparable" and decently portable
<bslsk05>
en.wikipedia.org: Comparison of instruction set architectures - Wikipedia
<epony>
you'll see there is certain line of CISC from mini to micro-computers that makes portability 'decent' despite word size and address mode changes
freakazoid332 has quit [Read error: Connection reset by peer]
freakazoid332 has joined #osdev
bgs has joined #osdev
alphajuliet has joined #osdev
k8yun has quit [Quit: Leaving]
alphajuliet has quit [Quit: WeeChat 3.6]
gxt has quit [Ping timeout: 258 seconds]
gxt has joined #osdev
m5zs7k has quit [Ping timeout: 265 seconds]
m5zs7k has joined #osdev
klys has quit [Quit: Lost terminal]
ZipCPU_ has joined #osdev
ZipCPU has quit [Ping timeout: 250 seconds]
ZipCPU_ is now known as ZipCPU
GeDaMo has joined #osdev
rurtty has joined #osdev
freakazoid332 has quit [Ping timeout: 268 seconds]
netbsduser has joined #osdev
zaquest has joined #osdev
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 260 seconds]
scoobydoo_ is now known as scoobydoo
travisg has quit [Read error: Connection reset by peer]
travisg has joined #osdev
LittleFox has quit [Remote host closed the connection]
LittleFox has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
scoobydoo_ has joined #osdev
scoobydoo has quit [Ping timeout: 265 seconds]
scoobydoo has joined #osdev
xenos1984 has joined #osdev
scoobydoo_ has quit [Ping timeout: 252 seconds]
vin has joined #osdev
<vin>
Where hard disk drives the first class of storage devices to support random accesses?
<vin>
Looks like tapes did not :o
Matt|home has joined #osdev
epony has quit [Quit: QUIT]
bauen1 has quit [Ping timeout: 265 seconds]
bauen1 has joined #osdev
nyah has joined #osdev
heat has joined #osdev
<ddevault>
I'm designing a capability space with guarded capability tables similar to seL4, but with the advantage of not having to use a depth parameter, and the ability for the kernel to allocate the next available capability address in a cspace automatically
<ddevault>
section 2 is everything you need to know
<klange>
vin: In the overall history of computers, sort of yes. Hard disks are incredibly old as far as computing goes - they were invented at IBM specifically to address the problem of random access on tape being infeasible, and existing random-access storage (various forms of memory, such as drums as core memory) being far too expensive to store large amounts of data
<ddevault>
my original design didn't call for this, it was just flat capability tables
<ddevault>
but it's rather complicated to place caps into another cspace than your own with such a design
heat has quit [Remote host closed the connection]
heat has joined #osdev
<ddevault>
note that this generally does not matter for most user programs, as far at they're concerned they'll just see a flat table
<ddevault>
(g=64-k)
smach has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
zid has quit [Read error: Connection reset by peer]
zid has joined #osdev
epony has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
frkzoid has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
smach has quit []
lkurusa has joined #osdev
<heat>
sorry i'll queue that on the reading list
<heat>
that being said, haha unixxxxxxxxxxxxxxxxx go brrrr
<heat>
i know this goes against "good software engineering practice" but i would implement that and go with it
<epony>
more like vzup, vzup, vzup, wheez, vzup, vzup, vzup
<heat>
most of the realities of operating systems can only be understood after actually doing it
immibis_ has joined #osdev
<epony>
show a non-UNIX system in use today ;-)
<heat>
as in, "is this a good design?" can only be understood after 1) implementing it; 2) using it; 3) measuring its performance and usability, security
<epony>
brrr is the sound note counting (bitcoin wannabe) machines do
<heat>
i dont understand your capability system (which i think is already a bad sign) but probably I'm just lacking context
<heat>
as in, "define capability" and "why do capabilities have addresses?"
<epony>
or understanding capacity, which is normal for uneducated individuals
<bslsk05>
en.wikipedia.org: Operating system - Wikipedia
<heat>
LMAO this dude is still going strong with it
<heat>
keep it up big man
<heat>
ghost bslsk05 queries are weird but i'll cope with it
<epony>
cope with Arm* programming instead ;-)
<epony>
got lots of work to do before you reach service level the likes of 70ies and 80ies computers
<epony>
make it a project goal to serve 10 and 100 users with an arm-computer, then we'll talk again
immibis_ has quit [Ping timeout: 268 seconds]
<epony>
the typical anti-Unix sentiments comes from people who do not understand system basics and implement single memory / data mixed space aplications running on virtual appliances.. for the joke of proving how much they do not know about computing
<epony>
the clean and elegant system is in your virtual domain
<epony>
so much old mentality in freshly minted youngsters.. can't get anything out of their words other than "everything" is "not understood" well enough
<mjg>
ok boomer
<heat>
least wrong thing in your OS
<epony>
try with ku (cool) and qu (suck) ;-)
<mjg>
i'm selling openbsd flamegraph NFTs
<zid>
(I did eventually decode the utf-8, but I no longer have the actual code)
<epony>
most wrong things on your lisp implementation
<zid>
I never got it integrated
<wxwisiasdf>
why the big red eyes
<wxwisiasdf>
it's creppy
<zid>
ayame is not creepy she is adorable
<wxwisiasdf>
ehhhhh
<heat>
everybody gangsta until the anime pfp's arrive and animesplain how itanium is highly superior to x86
<heat>
which tbf, they're not wrong
<wxwisiasdf>
but it's true
<wxwisiasdf>
itanium good
<wxwisiasdf>
intel bad
<heat>
and then the anime pfp's shit themselves when the furries arrive
<mjg>
ye you lose by having anime pfp
<heat>
furries are the last resort of low level programming
<mjg>
i guess you lose more by having a waifu, zid
<epony>
the big commercial success in Windows came from adapting Lisp machines to the RISC workstations and ongoing ARM computers massive boom in the business and high performance computing sectors (from mainframes to specialised supercomputers)
<heat>
you know at least vtubers haven't figured out how to write linux kernel drivers in rust for exotic hardw-
<wxwisiasdf>
that reads like the gnu/linux copypasta
<zid>
as in 'miku miku dance', I think, some software program people used to use to make animated music videos by hand animating 3d models
<zid>
it gives it a certain look
<epony>
mostly because of the fine and elegant organisation of the RISC machines which are superior to their joke immitation from the rest of the 99.9% business computers
<kazinsal>
heat: what you're referring to as linux is actually live2d/linux or as I prefer to call it-- *is shot from offscreen*
<bslsk05>
'Netflix Is A Joke - Home' - 'Dive deep into videos about all your favorite Netflix comedy shows. Netflix Is A Joke on YouTube is where the best comedic voices come to be themselves, flex their best jokes, and get some much-needed existential therapy from Bo Burnham.'
<epony>
there is also some heat on the side of failed online debates which argue against 100% sample rate of the computing industry progress
<zid>
What you're referring to as live2d/linux is actually live2d/iOS, sadly
<mjg>
heat: i'll take that under advisement
<zid>
apple refuses to sell the camera modules as a jellybean part
<heat>
what you're referring to as iOS is actually NetBSD/FreeBSD/Mach/iOS
<heat>
and what you're referring to as FreeBSD is actually FreeBSD/NetBSD/OpenBSD/DragonflyBSD
<heat>
praise the BSD code orgy
<zid>
What does the S stand for in BSD? I know the B is bondage
<heat>
sex
<zid>
bon-sex-dage?
<heat>
bondage sex denial
<epony>
last chapter, will span 2 lines.. https://en.wikipedia.org/wiki/X86#x86-64 "As a result of AMD's 64-bit contribution to the x86 lineage and its subsequent acceptance by Intel, the 64-bit RISC architectures ceased to be a threat to the x86 ecosystem and almost disappeared from the workstation market. x86-64 began to be utilized in powerful supercomputers (in its AMD Opteron and Intel Xeon incarnations), a market which was previously the natural habitat for
<epony>
64-bit RISC designs (such as the IBM Power microprocessors or SPARC processors). The great leap toward 64-bit computing and the maintenance of backward compatibility with 32-bit and 16-bit software enabled the x86 architecture to become an extremely flexible platform today, with x86 chips being utilized from small low-power systems (for example, Intel Quark and Intel Atom) to fast gaming desktop computers (for example, Intel Core i7 and AMD FX/Ryzen), and even
<bslsk05>
en.wikipedia.org: x86 - Wikipedia
<epony>
dominate large supercomputing clusters, effectively leaving only the ARM 32-bit and 64-bit RISC architecture as a competitor in the smartphone and tablet market."
<heat>
don't kink shame
<kazinsal>
BSDM stands for Berkeley Software Distribution Mommy
<heat>
HAHAHAHA THE DUDE DOESN'T FUCKING STOP
<heat>
THIS IS HILARIOUS
<zid>
what dude?
<kazinsal>
(that one worked better in my head)
<zid>
kazinsal: I laughed
<zid>
It was great
<zid>
just tacking mommy onto the end is kinda great
<heat>
zid, yeah i ignored him too
<zid>
it's non-sexual then suddenly spikes to the moon
<zid>
ignored who
<heat>
the guy who keeps ranting about x86 good everything else bad
<zid>
oh, x86 is good and everything else is bad though, risc only goes up to like 5
<epony>
heat is ignorant and demonstrates that by ignoring people on his discussion which is mostly useless ;-)
<zid>
motorola went up to 68
<heat>
no
<zid>
apple is only at 2
<heat>
it went up to 68k
<heat>
it's unbeatable
<zid>
68 degrees above zero
<zid>
mine runs at like 400
<heat>
is that the new intel cpus' Tjmax?
<zid>
new cpus have kind bad tjmax
<zid>
my p4 had 100C
<heat>
whaaaat
<zid>
my sandy is like 92C
xenos1984 has quit [Ping timeout: 250 seconds]
<epony>
heat, the point was, if some ignorant person says "that architecture is bad" and then fails to deomonstrate it, and concludes with "someone else rants about the superiority against my fake claim", we can safely dismiss that stupidity (and hyprocricy)
<heat>
the i9-12900k has 100°C
<heat>
not bad
<zid>
oh good, back on form
<wxwisiasdf>
IBM gave birth to Intel
<zid>
like, deformed birth they kept in the attic?
<wxwisiasdf>
Intel gracefully answered by stealing all their marketshare
<heat>
failed abortion
<zid>
intel won't tell me my tjmax, it just says "Tcase 64C"
<wxwisiasdf>
lmao
<kazinsal>
intel went up to 80486, but motorola went up to 88000 (very briefly)
<zid>
ah 98C says google
<epony>
it tells you the Tj alright, you just can't read spec sheets
<zid>
This one wouldn't get to 4GHz on old psu, I took it to 4.5 and it was stable on this one but it gets a little.. warm
<kazinsal>
speaking of PSUs I was reading the new ATX 3.0 PSU spec and was pleasantly surprised to find that the 4-pin sideband signals on the PCIe Gen 5 power connector aren't some crazy "let's put IIC next to a 600 watt +12VDC cable bundle" thing
<zid>
needed some bonus volts, this is 'overclocked' to 4.2 and undervolted
<heat>
Tcase sounds fucking stupid
<zid>
Those connectors are hilarious kazinsal
<epony>
it would be nicer to bridge twitter and facebook, not just matrix and discord.. cause the expertise there would exceed yours here from yesterday and today, on the 2 chat bots taalking to each other with 3 word sentences incessantly
<zid>
they're rated for 30 insertation cycles
<zid>
because they have little barbs that scratch the metal for a gooder connection
<kazinsal>
yeah the reduced pitch on the main power pins scares me enough
<kazinsal>
all the little electrical connectivity details on top of that are a big ol yikes
dude12312414 has joined #osdev
<epony>
you're using BGA chips on 20 year old legacy process anyway
<zid>
Figuring out how to get my bios to do all core turbo overclocking without disabling load line calibration was a thing though
<heat>
have u considered that maybe u shouldn't overclock a xeon
<heat>
just saying
<zid>
why not, it's fully unlocked
<zid>
it's just an i7 but better
<zid>
i9 even
<heat>
it's big and bulky and consumes a lot of power
<zid>
i9 with ecc and quad channel
<heat>
and purposefully underclocked
<zid>
it's not purposefully underclocked, it's HEAVILY SEGMENTED
<kazinsal>
it's sand that thinks. sand wasn't meant to think. punish that thinking sand with MOAR VOLTZ
<zid>
It's actually running *less* volts
<zid>
it's a 1.3V VID
<epony>
one of the experts demonstrates expertise by being unable to locate their halt instruction, the other goes on about chip enclosures without really using that either ;_)
<zid>
I have it at 0.8-1.2, with an overclock
<zid>
oh right I should check ebay for rams
<epony>
that would be the worst place to get your memory and storage units.. (or electronics for anything other than school projects)
<zid>
people keep bidding £25 but that's all I have in my paypal and that doesn't leave any for postage
<heat>
i giv eu moneys first and u give me cpu after yes???
<zid>
yes
<zid>
That's how it works
<zid>
also the testing fee is included
<zid>
I will make sure it boots
<heat>
do u need my cvv?
<epony>
and as a final demo of the "fake claims".. the duo is discussing their revered hype about purchasing a third hand desktop CPU from the "hated" x86 platform ;-)
<zid>
no just paypal to z*dsoft+payp*l@g*ail.com and write "€50" into the box
<zid>
free shipping
<zid>
item fully tested
<wxwisiasdf>
:)
<zid>
bruhs, nobody is going to spend £80 on your fucking 4x4GB hyperx, stop listing this stuff
<epony>
"cruel nature has won again" --the mensa club
<heat>
lmao
<heat>
16gb ddr3 80 pounds bruv, good price innit
xenos1984 has joined #osdev
<heat>
as ye can see, it's gamer ready memory
<zid>
Only idiots like me would even consider it, and I don't need 4GB dimms anyway
<heat>
you do have quad channel
<heat>
might as well use it
<zid>
right, and I want 32GB of ram
<zid>
so I'm going for 8x4
<zid>
I have 2x8 and 2x4 atm
<zid>
cus that's what was in the desk drawer
<zid>
and the 2x4 kit is slow as shit
<wxwisiasdf>
:3
<zid>
I see some hyperx BEAST but I think it might be too tall to fit under my cooler
<zid>
I'm still on the lookout for a 786, can only find 686s so far
<heat>
holy shit what a link
<zid>
yea you need to remove everything after ?
<zid>
It's just your blood group etc in base64
<heat>
is this like amazon where your search gets posted in the link?
<zid>
blood group, age, height, weight, socioeconomic status
<heat>
poortugal
<wxwisiasdf>
786 would've had 10 billion pipeline stages probably
<zid>
poor tugal :(
<heat>
anyway the 486 is the ideal cpu
<heat>
pre cpuid (pre confusion), has invlpg
<zid>
is there anything we can do to help tugal?
<heat>
send mone
<zid>
MEND SONNY
<zid>
heat why are you so poor
<zid>
do you keep buying too many candles
<zid>
hmm maybe it's the avocado toast
<heat>
avocado toasts and communism
<GeDaMo>
You have to pay for your communism? :|
<zid>
I like communism, you should share your ram with me
<zid>
GeDaMo shares his toothbrush with me
<GeDaMo>
That's not the one I use for brushing my teeth :|
<zid>
oh I was about to say I needed something to clean the grout in my bathroom
<heat>
uh oh
<zid>
so I guess neither of us are brushing our teeth with it
<heat>
i assume your bathroom is gonna smell a lot more like ass
<zid>
we should have an osdev meetup heat, we can find a cardboard box to chill out in
<zid>
and talk shit about solaris
<zid>
food will be whatever we can wrestle away from the seagulls
<heat>
i dont talk shit about solaris
<heat>
except doors
<heat>
doors is inherently funny
<zid>
we could go to the bathroom and experience pure streams based networking
<heat>
sgtm
<heat>
where though
<zid>
portapottytugal?
<heat>
stgm
<heat>
anywhere in europe really
<heat>
preferrably GMT+0
<zid>
pooris?
<heat>
i want to make all the PNW people come here
<zid>
papau new.. whinnie
<heat>
and experience e u r o p e a n f r e e d o m
<zid>
portugese new world?
<zid>
is that brazil
<heat>
obviously
<heat>
and the rest of the colonies too
<heat>
having an indian colony never goes out of style
gog has joined #osdev
<heat>
gog
<gog>
heat
<heat>
osdev meetup where
<heat>
your choice
<gog>
rvk
<gog>
i don't wanna fly anywhere
<heat>
u can swim no
<gog>
yeh i'll just swim across the north atlantic it'll be great
<zid>
goa is a cool palce
<zid>
you fucked each other's cuisine up there so it has some neat dishes
<heat>
if the vikings rowboated to america u can swim to europe
<zid>
I'm sure gog can rustle up 80 strong men to do some rowing
<heat>
is that what grindr's for
<gog>
80? idk where i'm gonna find 80 men in iceland that's 2/3 the population
<zid>
tourists
<zid>
american army base
wootehfoot has joined #osdev
<zid>
walrus in a trenchcoat
<gog>
oh right they started using it again
<zid>
8 cod in a parka
<heat>
rocks
<zid>
40kg of moss in a sack
<gog>
i'll do it myself
<heat>
rocks are great
<gog>
i need the exercise anyway
<heat>
i really rate iceland
<heat>
rocks and colored roofs
<epony>
^ and drowner bots doing useless spam with fake worded non-sentences of empty words
<zid>
Iceland is great, I'd give it one
<heat>
“Your existence is a light 1. And the 1 is ‘cause you are alive. And ‘cause you somehow wifed a Black girl. I’m feeling a light to decent 1 on your existence.”
Gooberpatrol66 has quit [Remote host closed the connection]
netbsduser has quit [Remote host closed the connection]
<zid>
we're so hinged that you get that sort of super-flat effect from rick and morty by looking at us
<heat>
mjg, are you jealous or what
<heat>
you can also come and take a look at my flamegraphs dont worry
<mjg>
you know, i was tempted to look at obsd flamegraphs
<mjg>
but last year i made myself a promise to not look at their shit
<heat>
good
<zid>
mjg: You might not be aware of this, but you spent most of this week talking to a dirty foreigner over the phone network about locking primitives, glass houses and all that
<mjg>
zid: and it was for nothing, as the relevant benchez were already faster than obsd
<mjg>
:[
<heat>
*pessimal*
<zid>
that's because his code doesn't do any work, he just likes big benches and he cannot lie
<mjg>
although i think the patched state got it ahead of netbsd?
<heat>
yeah
<mjg>
i take it
<heat>
same
<heat>
now I just need to make it *safe*
<heat>
I still haven't passed dirconc
<froggey>
errno is a disaster. utterly terrible
<heat>
for sure
<mjg>
funny you mention that rename thing
<heat>
what's your rant tonight
<zid>
errno's problem is that it's singular
<mjg>
i had a quick look what would it take to sensibly add the rename lock
<zid>
if *lots* of things were like errno it'd just be normal
<mjg>
ufs rename is so fucking stupid i gave up
<heat>
goto igiveup;
<mjg>
goto hangyourself;
<heat>
yo that got dark real quick
<mjg>
well let me rephrase, i could still do the following:
<mjg>
if VOP_RENAME is provided, roll the current way
<mjg>
otherwise if VOP_RENAME_UNFUCKED is provided, go the new & unfucked way
<heat>
zid, errno's problem is that it's a bad idea
<heat>
functions could just return status code ez
<mjg>
you are calling a unix concept a bad idea
<zid>
what if you wanna return TWO status codes
<heat>
hey this is a standard C concept
<mjg>
ritchie rolling of laughter
<mjg>
zid: ikr, one the current errno, another one random
<heat>
that's already possible if you're not careful reporting errno!
<zid>
That's my new ABI btw
<zid>
rdx must contain a random number
<zid>
its quality will be checked, and if it falls too low, your program will be OOR killed
<zid>
(out of randomness)
<heat>
sgtm
Gooberpatrol66 has joined #osdev
<heat>
i think a real flaw in C is that you really can't standardly return two values
<heat>
or at least not in an efficient way
<zid>
it'd be nice to be able to make tossaway tuple structs somehow
<heat>
then you have to choose between
<heat>
int errno; if(!malloc()) see_errno
<heat>
or int st = malloc(&ptr); if (ERROR(st)) stuff(st); else ptr
<heat>
both of which are annoying
<heat>
the last one being very Wintel
<heat>
I like linux's thing where they return values in pointers by reserving the upper 4096
<zid>
Go reserves the entire bottom 4GB
<zid>
so you get the entire int range
<heat>
but it's also admittedly hacky
<mjg>
zid: wut?
<zid>
(I think it's so its GC doesn't get confused)
<mjg>
what happens on 32 bit
<zid>
what's 32bit
<heat>
you get no memory
<mjg>
they support 32 bit archs
<heat>
dirty 32-bit users get no right for memory
<zid>
what like.. gameboy or something?
<mjg>
i know because there is lollery there
<mjg>
to faciliate it
<mjg>
facilitate even
<mjg>
i386, at least linux and *BSD
<zid>
wait, i386 existed?
<zid>
I thought it was like 8051, where sure it existed, but nobody actually used them for anything you've ever heard of it
<zid>
just random kid's toys
<mjg>
you are not going to weasel your way out of this one dawg
<mjg>
how can the above work if they reserve 4G
<zid>
I assume they just let the GC get confused
<zid>
and don't do it on 32bit
<heat>
anyway I like Rust's Result
<heat>
or C++'s expected
<heat>
the problem is that it's hard to define them in a space efficient way
<heat>
so you get something like
<heat>
(pardon my C++)
<heat>
template <typename Result, typename ErrorType> class expected { union { Result res; ErrorType err; }; bool is_err};
<heat>
the problem being that is_err is always there because unions are hard :(
<j`ey>
rustc tries to optimise space based on the type, pretty cool
<zid>
lua is the only language I've used that lets you return arbitrary trupeusprles
<zid>
I hate lua, but that was kinda handy
<heat>
j`ey, how?
<zid>
I do worry about what it does to the code though, as with any 'innovation'
<heat>
zid, you can also return tuples with std::pair<Type1, Type2>
<heat>
I don't know if that's what you mean by arbitrary though
<zid>
I can for example, imagine big kitchen sink functions you're expect to extract the args you 'want' out of
<j`ey>
heat: for example: Option<&T> will use the fact that references are never null to encode the 'None' value as 0
<heat>
ah
<heat>
coooooooooooooolio
<heat>
also RIP coolio
<kazinsal>
typedef struct { bool success; union { void *ptr; uintptr_t u; intptr_t i; int err; }; } result_t;
* kazinsal
runs away cackling
<zid>
I wonder if any languages do.. parameterization templating? whatever it's called? where you do f(x) or f(x, y) and it calls two different functions? but for the number of return args
<heat>
kazinsal, dudeeeeee no
<zid>
so x = f() calls a different function to x,y = f()
<heat>
bool first will fuck up your struct with padding
<heat>
you'll get struct { bool success; char padding[7]; union {void *ptr; ...};};
<zid>
heat, what is that called, and does any such language exist
<heat>
idk im no language expert
<heat>
I know C++ doesn't because there's no return-type-based overloading AFAIK
<zid>
Okay let's play guess the word. I am thinking of a word, and it starts with "heat is useless as us___"
<heat>
that's a hard one
<heat>
can i get an easier one zid
<zid>
okay, The us___ approach to talking to heat, is to cringe
<zid>
the answer was of course, usurp
<heat>
oh oh oh I know
<heat>
usnea
<heat>
j`ey, but does rust do it for Result though?
<heat>
because that seems pretty unportable
<zid>
heat when are you usurping the BSDs in totality?
<heat>
never
<heat>
I write budget linux not budget bsd
<zid>
I think you could actually pull the latter off though
<j`ey>
heat: unportable? but yes it does it for all enums
<zid>
it should take what, a couple of weeks to be better than BSD?
<mjg>
in what sense
<mjg>
you can definitely overtake netbsd within weeks
<froggey>
every sense
<heat>
install base
<froggey>
sight, smell, taste, etc
<mjg>
3rd eye
<mjg>
heat: support ufs!
<heat>
j`ey, i'm talking about something like encoding the result in a single variable as linux does with ERR_PTR
<mjg>
i sed to dislike ERR_RPTR but i warmed up to it
<heat>
which is pretty portable in theory but unportable in practice
<heat>
sorry
<heat>
portable in practice, unportable in theory
<heat>
as in the magical C/C++ abstract machine will flip you off
<mjg>
kernels alreday depend on UB
<mjg>
and i don't mean when interacting with hw
<j`ey>
heat: its portable wrt rust yeah
<heat>
yeah i mean for a general, standard thing
<heat>
>support ufs!
<heat>
which one
<heat>
there are like 30 of them
<heat>
i already support ext2 too sooooo
<heat>
i can cross that off my list
<heat>
i actually tried implementing an mke2fs
<heat>
didn't work out well
<heat>
most tools don't tell you exactly what they didn't like, and I can't bother recompiling
<mjg>
ye i remember being surprised to find that obsd and fbsd have incompatible on disk formats for the sucker
<mjg>
i suspect the latter can simply adjust some defines to work again with it
<mjg>
you know what would be funny, SOLARIS UFS
<heat>
do they not have it?
<mjg>
i would love if you won against illumos in the open benches, but again you can't really test them in the vm :[
<mjg>
they do have it, i mean if you could rw it
<heat>
it doesn't surprise me that you guys are incompatible
<heat>
the UFS wiki page is hilarious
<mjg>
solaris vs bsd is pretty obvious
<mjg>
cross bsd really is not as there was code flowing
<heat>
everyone is stupidly incompatible and linux has a read only UFS driver which "works" maybe
<mjg>
most notably for stuff like soft updates
<heat>
and can't write
<CompanionCube>
why can't you test them in the vm
<mjg>
CompanionCube: they use rdtscp a metric fuckton, which floors performance in this case
<heat>
rdtscp
<heat>
but I also do it
<mjg>
not anywhere near to their extent
<heat>
in fact I do a pessimization of rdtscp
<mjg>
i rmeember a mere read() is like 4 extra calls :D
<heat>
anyway I'm not particularly sure rdtscp vmexits in qemu
<mjg>
should be easy to test
<heat>
as in it would be visible AF in the flamegraphs
<mjg>
plug ig it int owill-it-scale
<mjg>
and compare vs bare metal
<mjg>
in fact i did that some time ago, maybe i have a file somewhere
<bslsk05>
github.com: Onyx/kernel/kernel/net at master · heatd/Onyx · GitHub
<heat>
use it and find bugs for me thanks
<CompanionCube>
mjg: yes
<mjg>
someone decided to implement "vrtual network stacks"
<mjg>
in freebsd
<mjg>
which also means there needs to be a way to shut the thing down
<heat>
what's that dad
<mjg>
but the original did not have any
<mjg>
after much swearing and losing 3/4 of the liver someone got it to the point where this basically works now
<mjg>
but there are still tons of races vs iface removal etc
<heat>
ok but what's a virtual network stack
<heat>
is it a networking namespace?
<CompanionCube>
poor liver
<heat>
or as freebsd would call it, LITERALLY JAIL
<mjg>
it's literally a dedicated network tsack, you can run a dedicated firewall on it
<zid>
ethernet packet? straight to jail.
<zid>
appletalk packet? straight to jail.
<mjg>
all network access is abstracted
<heat>
sendmsg? you guessed it, jail
<mjg>
underage porn? jail
<heat>
@rms
<mjg>
i do think the fetaure is quite nifty now that it mostly works
<zid>
mjg just meming instead of helping :(
<mjg>
ok fine
<heat>
zid, if u do want help i linked you my entire stack
<heat>
the design is decent
<mjg>
if you genuinely have a question concerning smp or vfs, i can try to answer
<zid>
okay here's one
<zid>
for smp, do people generally have a 'universal' entry point that every cpu uses, or do they just spin up a new 'process' for new cpus to run
<zid>
idk what other people do I do 0 research
<zid>
on anything
<heat>
wdym a new process?
<zid>
IPI them awake into an iretq, I guess?
<heat>
generally you have an entry point when bootstrapping that ends up in an idle loop/idle thread
<heat>
but that goes through init first
<heat>
so INIT SIPI SIPI, cpu comes up, gets into protected/long mode, jumps to the proper kernel
<zid>
my thinking was you can either wipe its arse for it, or make it wipe its own arse
<mjg>
i think the q is if every cpu has its own idle thread
<zid>
nah
<mjg>
and normally that's how its done
<heat>
then in the kernel it inits itself, sets up percpu shit, whatever
<heat>
then ends up idling
<zid>
Like, you can set up all its page tables for it, set up all its percpu shit etc, then just poke it awake and it does nearly 0 init
<zid>
or you could just poke it awake in some early init code and make it do it all itself
<heat>
the page tables are pretty much required to be set up
<heat>
percpu, meh, you can do both ways
<heat>
but usually it's best to set up percpu right at the beginning
<heat>
as in, you can actively break things if percpu isn't set up
<zid>
so do you treat kmain as 'cpu0 entry point' and just give them a subtly different cpu1+ entry point that is almost the same but doesn't init as many things?
<heat>
i.e imagine you need to malloc for that space, malloc does spin_lock, spin_lock disables preemption, preemption disabling touches a percpu variable, boom
<heat>
oh no the cpu1 entry point is totally different
<zid>
that's what I'm asking, how much arse-wiping do you do for them
<heat>
some
<zid>
:D
<heat>
page tables, gdt, idt is done
<zid>
so like kmain but less?
<heat>
stack is also allocated
<heat>
percpu is also allocated
<heat>
it also gets its own thread that's already allocated
<zid>
split kmain into 'things only one cpu needs to do' and 'things every cpu needs to do'
<heat>
it pretty much arrives in C++ land, does some init, and goes into an idle loop as the idle thread
<zid>
and one cpu includes 'setting up the other cpus'
<zid>
then they all enter that second half
<heat>
very few things are "things every cpu needs to do"
<bslsk05>
github.com: Onyx/smp_trampoline.S at master · heatd/Onyx · GitHub
<zid>
and you wake them all up in advance, rather than waiting for them to actually have something to do
<heat>
yeah
<zid>
I have an actual question I should already know the answer to if you want
<heat>
I do most of the work on the BSP because it's super hard to bring them up without all of them in place
<heat>
sure
<zid>
when you block in a syscall
<zid>
actually nevremind I think I just answered it trying to ask it
<heat>
go ahead stupid
<heat>
im waiting
<heat>
as a bigshot BSD competitor i've got places to be, you know that
<zid>
I was just gunna say how do you like, transition your stack into the idle thread so you can be scheduled away or whatever, but then I realized it sorta just works, put an iretq after leaving the idle loop, fuck the contents of the kernel stack
<heat>
i just switch stacks
<zid>
you don't care you came from read(), as long as the data-has-arrived-code sets things up
<zid>
which might not even be the same cpu
<heat>
in my design each idle thread is pinned to each CPU
<mjg>
heat: you keep talking shit and i'll patch some netbsd to beat you at openro
<heat>
so when I block, I just switch
<heat>
I don't know if the next thread is the idle thread
<heat>
it may very well be another thread
<mjg>
and have the idle thread's main loop figure out what to do, e.g. maybe power down
<mjg>
after some time waste
<heat>
so in my scheduler the lowest priority really is for the idle threads to sit in
<zid>
cpu18 does read, ends up inside kernel_read(), that knows it will block, so calls go_idle(). Data arrives on cpu7, do you now wake cpu18 up and tell it to deal with massaging the buffers and copying them to userspace etc, or does cpu7 do it?
<zid>
cpu7 doing it seems far easier, but it has to work on a 'remote' pagetable which is lamer
<heat>
oh that's totally 18
<mjg>
it should not go_idle()
<heat>
and yeah, not go_idle()
<mjg>
it should go_off_cpu_for_now()
<zid>
yield()
<mjg>
and that maybe will be idle, maybe another thread
<heat>
sure, a special yield
<zid>
idle being synonymous with "go do other shit"
<heat>
18 does it because it's 18's job
<heat>
7 doesn't have the page tables, nor the context
<heat>
nor the caches, etc
<zid>
yea, 7 would be sucky, cus of the remote pagetable issue
<zid>
oh if you kick 18 awake I guess it just returns from yield() into the latter half of kernel_read() anyway
<zid>
so it can just do it there anyway
<heat>
yup
<heat>
exactly
<zid>
yea that works how I thought it'd work, but I just wanted to make sure the things I thought were sane were sane
<zid>
cus I never do research
<heat>
you should look at the sources
<zid>
I just write it off the top of my head
<zid>
that's less fun
<heat>
no, it's more fun
<zid>
heat training to be a parrot
<heat>
i more or less know the linux kernel by heart
<heat>
just by studying it
<zid>
you poor thing :(
<heat>
dude
<heat>
tiancore is like
<heat>
way worse
<mjg>
a commentary on the linux operating system
<heat>
tianocore*
<zid>
heat when is your novel coming out
<zid>
"The design hits and misses of the linux kernel, by Poor Tugal"
<heat>
hits:
<heat>
ebpf iouring hehe
<heat>
misses:
<heat>
/proc
<heat>
/dev
<heat>
supporting zfs at all
<zid>
I am going to make SUPERPROC
<heat>
purchase volume 2 for the next misses
<zid>
did you see my DESIGN DOC
<heat>
no
<zid>
It's going to expose the entire everything, like sys/proc, but via html
<zid>
with graph views
<heat>
oh fuck yeah
<zid>
like you have AIDA64 installed on windows or something