klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
<jimbzy> Crazy.
<klange> Late '02.
<geist> that was my first experience with ARM since we had a little kernel that ran there
<geist> arm7tdmi, i think 24Mhz and then later 48Mhz
<jimbzy> Made my Palm m105 look sad.
<klange> I would have had my Jornada 520 at the time.
<klange> rx3715 would have been a year or two after that...
<geist> yah years later i got a jornada to fiddle with
<geist> was kinda neat, but couldn't find a use for it
<klange> I still have both of these, and shockingly actually in my house right now.
<klange> My rx3715 was a factory refurbished unit and the camera couldn't focus correctly.
<klange> Not that it really mattered, it was so terrible you couldn't tell the difference.
<klange> It had a beefy IR blaster and came with a universal remote app, so as a teenager you can imagine how much fun I had with that programming it with random power button signals for TVs :)
<jimbzy> Yeah!
<jimbzy> I'm pretty sure my palm had that and I used it to control my Robosapian.
<klange> I think the most amazing thing, to me, about the handheld computing market at that time, was just how many models there were... especially compared to how few buyers there were
<klange> i swear there's fewer smart phones on the market now despite a million times the market share
<sonny> yep
<sonny> I'm still waiting for some handwriting tech to come back
<moon-child> I want a small phone
<moon-child> currently rocking an iphone se (1st gen)
sortie has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
<gog> oookay switching to clang is proving to be more problematic than i anticipated
<gog> specifically, my loader beign a native UEFI application built with clang
<gog> rather than gnu-efi trickery
<gog> guess i'll figure it out later
<klange> a neat trick you can do is use a mingw toolchain to build EFI apps
<sonny> gog are you using clang on windows too?
<klange> I do that for my Kuroko EFI builds, but the EFI loader for Toaru still uses the gnu-efi toolchain with elf-to-pe objcopy magic.
<heat> gog is using clang as a uefi toolchain
<heat> clang, the best free open-source liberally licensed toolchain
<sonny> yeah, if not I'd have to use linux for osdev
<klange> There is some irony to how little I use clang given 1) my name, 2) the fact that LLVM came out of my uni
<heat> you are going to have to use linux for osdev
<heat> or freebsd!
<klange> I got my whole toolchain set up on macOS, I'll have you know!
<sonny> freebsd is cool
<klange> On an M1! Sure I had to patch a bunch of stuff to get gcc to build at all, but I got there in the end!
<klange> https://klange.dev/s/Screenshot%20from%202022-03-18%2009-50-47.png ← GCC 9.3-win32 from the mingw toolchain packages on ubuntu :D
<heat> I build toolchains for macOS as well even though my OS probably can't build on native macOS
gog has quit [Ping timeout: 240 seconds]
<heat> it might be able to if you do a bunch of brew for gnu utils
<heat> don't know about fallocate though, I use that a bunch
<klange> My ARM builds have far fewer requirements.
<klange> Still need Python for my dirty tar trickery, but there's no ISO building, no FAT filesystems; GNU Make, GCC, and Binutils, plus a local build of Kuroko but I've been testing that on macOS for ages now.
<heat> kuroko is only the second python-like interpreter to run on edk2
<heat> the first one being literally python
<klange> Didn't that Python port require a lot of EDK tooling? This is bare EFI.
<heat> it only depends on edk2-libc I think
<heat> which is a (poor) libc implementation for UEFI
<klange> yeah, my libc footprint in Kuroko is so microscopic I just copied a couple of functions in myself.
<heat> but it's actually upstream which means people actually use it
<heat> which is scary
<klange> My fancy new 64-bit printf was written for this before it got to my OS.
<heat> there's also Lua which is better
<klange> Lua is also realy small on the libc footprint, very good for embedding.
[itchyjunk] has quit [Ping timeout: 240 seconds]
<heat> I don't get why anyone would want scripting in firmware land
<heat> it's very scary
<klange> I think it's cute to get to "something a user can do fun stuff in" as soon as possible.
<klange> It's like the old days of home micros.
<klange> Booting straight to basic.
<klange> That's the dream Terry had when he was still coherent.
<heat> right
thinkpol has quit [Remote host closed the connection]
<heat> but these things are submitted by people that work for intel
<heat> it's not a hobby
<klange> Intel wants it for a flexible test environment.
<heat> testing what?
<klange> Boot straight to something more easily programmable than the bare EFI, but without all that OS baggage on top.
thinkpol has joined #osdev
[itchyjunk] has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.4.1]
<geist> thats a point. they probably implement diagnostics and whatnot on top of EFI
<sonny> heat why is scripting scary?
<mrvn> klange: logo with turtle graphics
<heat> because you're running a python interpreter as part of the firmware
<heat> although tbf, it's not in flash but as a EFI application, so it's not that bad
<mrvn> no way, firmware runs Forth.
<klange> Was it part of the firmware? It's just an app that runs _on_ the firmware. EFI was somewhat designed around the idea of having applications other than just OS loaders
<heat> yeah I guess it's not so bad
<CompanionCube> you can also do EFI shell scripting, no?
<heat> i think so but it's weird
<CompanionCube> mrvn: what do you think this is, SPARC?
srjek has joined #osdev
<heat> what if I slap an actually decent libc on top of UEFI, then port make and gcc
<heat> I could literally build edk2 on top of edk2
<heat> firmware that builds itself
<heat> I love it
<CompanionCube> i vaguely recall some kind of emacs on openfirmware or something
<CompanionCube> ah yes, someone made microemacs 3.7 into an openfirmware client
<klange> I wanted to do a port of bim to EFI. A lot of what went into the Kuroko EFI port was getting my line editor working, which is based on an old version of bim anyway.
<geist> i alwys think of those complex gui shells in modern bios config stuff as basically an example of what you could build on UEFI ifyou wanted
<geist> though unknown of the average one of thost actually runs as an official UEFI app or just a sidecar to the firmware
<geist> never bothered to look around inside the rom firmware on one of tose to see if you can find the apps stored in some sort of internal file system
<heat> everything is an app or a driver
<heat> no in between
<heat> EDK2 has a firmware filesystem
<moon-child> not sure how useful that would be in practice. Since they require access to hardware-specific stuff anyway, they won't really be portable. So, could do the ui in efi; but probably it's a shared codebase, maybe actually based on a shared vendor-specific abstraction library
<moon-child> so eh
<geist> yah exactly
<heat> they are UEFI apps
<heat> they're just not in the ESP of course
<geist> yu could easily build an app that gets direct access to stuff, since nothing keeps you from doing it
<geist> since you can ask for APIs by UUID seems ike you could build whatever backdoors into your firmware you wanted
<heat> if you use a tool to decompile firmware images you'll find a lot of individual .efi files containing drivers, apps, etc
<mrvn> can you list available UUIDs?
<heat> geist, I bet they don't bother using protocols but rather just statically link everything
<geist> possible
<CompanionCube> also listing uuids would be a crap plan to discover hypothetical backdoors
<heat> you can list handles and with the handles you can list protocols installed on them
<geist> also possible most of it simply reults in WriteConfigBlob()
<CompanionCube> i know on my firmware there's a surprising number of exposed config in uefi variables
<heat> bet it's XML
<geist> heat: you really dont have a high opinion of this do ya? :)
<bslsk05> ​p.ahti.space <no title>
<heat> boot options, boot to file, etc are all efi variables afaik
kori has quit [Quit: zzz]
<heat> geist: high opinion of what? edk2? The XML comment is just me being snarky :)
<geist> yeah
<CompanionCube> also
<heat> edk2 is fine, there are some things I don't agree with but I really like the project
<CompanionCube> fun fact: file /sys/firmware/efivars/* results in SIGABRT.
<geist> CompanionCube: that means you're onto something!
<geist> *they* dont want you to know
<heat> oh yeah I'll probably be a (junior) mentor in this year's tianocore gsoc for 2022!
<CompanionCube> geist: and to stop this something corrupted the malloc metadata
<heat> that's weird, it works here
<CompanionCube> evidently a file is causing bad juju
<CompanionCube> gdb is useless, but: 'Core was generated by `file /sys/firmware/efi/efivars/AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5'
<heat> your efivars look pretty standard
<heat> + a bunch of linux kernel dumps
<CompanionCube> only the one, i think
<CompanionCube> hm, actually two, right.
<heat> all the dump-type0 ones are kernel dumps
<CompanionCube> yes, but there's only two of them
<CompanionCube> they just happen to have many parts
<heat> maybe
<heat> i dunno how those dumps work
<heat> the only thing I don't really like in edk2 is the fact that they build openssl for https support
<heat> i feel like you could find some alternative to openssl
<heat> I know arm has been developing mbedtls
sonny has quit [Quit: Client closed]
<heat> but nasty firmware tricks are way less frequently, or at least I just can't see them :)
<heat> I have found an XML library in microsoft's project mu but apparently it's only used to report unit test statuses, which is OK
<heat> (but at the same time, really? XML?)
srjek has quit [Ping timeout: 240 seconds]
eddof13 has joined #osdev
eddof13 has quit [Ping timeout: 240 seconds]
sonny has joined #osdev
sonny has quit [Client Quit]
<heat> I broke clangd
<heat> 7 gigs of swap and all cores pegged
<Griwes> clangd is one of the primary reasons I went with 128 gigs of ram for this laptop lol
<milesrout> who ever thought C++ was a good idea
<milesrout> oh Rust.. well
<heat> nah that was all clangd
<milesrout> basically the same thing from a compilation-breaking-my-computer perspective
<mrvn> it's easy to write exponentially expanding templates accidentally.
<heat> I wasn't even compiling
<mrvn> FINAE to the max
<milesrout> i've actually blacklisted rust pretty thoroughly on this computer
<heat> just had vscode open and it was indexing with clangd
<heat> the whole of fuchsia
<milesrout> rustc is masked and the new versions of any package that requires rustc to be built (like newer versions of librsvg) are masked too
<heat> that's weird
joe9 has quit [Quit: Lost terminal]
Belxjander has quit [Ping timeout: 252 seconds]
sonny has joined #osdev
<raggi> You can tune clangd with some flags to index in the background and limit workrate etc
eddof13 has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
rorx has quit [Ping timeout: 272 seconds]
scoobydoo has quit [Ping timeout: 272 seconds]
ravan has joined #osdev
sonny has quit [Ping timeout: 256 seconds]
Burgundy has joined #osdev
garrit has joined #osdev
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
* kingoffrance reads backlog
<kingoffrance> perl....would be interesting if it was actually "native" and not "hosted" ...
<kingoffrance> *freestanding
ElectronApps has joined #osdev
fkrauthan has quit [Quit: ZNC - https://znc.in]
fkrauthan has joined #osdev
fkrauthan has quit [Client Quit]
fkrauthan has joined #osdev
<gorgonical> so when defining where memory starts, where the bootloader lives, etc. That's defined by the board or by the soc?
<gorgonical> As in, will all Allwinner D1 boards share the same memory maps on the hardware?
<clever> gorgonical: i think it varies some, the hardware usually defines where ram begins, but then the bootrom defines where the SPL lives, and the SPL defines where the bootloader lives and so on
<gorgonical> Right, so the hardware is just the soc package?
<clever> yeah
<gorgonical> So existing D1 board info for super early boot should be applicable for other boards
<gorgonical> Not that I'll be doing that much mucky work, it's already done
<clever> yeah, assuming no software like ATF has stolen chunks of ram
rorx has joined #osdev
heat has quit [Ping timeout: 250 seconds]
Clockface has quit [Ping timeout: 240 seconds]
<clever> gorgonical: but some hardware like the rpi, can move ram/mmio arround freely, though the official firmware doesnt move it very much
alpha2023 has joined #osdev
alpha2023 has quit [Ping timeout: 245 seconds]
<gorgonical> took entirely too long to find the memory map in the manual
nj0rd has quit [*.net *.split]
netbsduser has quit [*.net *.split]
ssiyad has quit [*.net *.split]
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Max SendQ exceeded]
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Max SendQ exceeded]
the_lanetly_052 has joined #osdev
ssiyad has joined #osdev
nj0rd has joined #osdev
netbsduser has joined #osdev
ssiyad has quit [Max SendQ exceeded]
the_lanetly_052 has quit [Max SendQ exceeded]
ssiyad has joined #osdev
the_lanetly_052 has joined #osdev
<gorgonical> the inconsistency with which risc-v chips are given their extension codes makes research hard
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
scoobydoo has joined #osdev
eddof13 has quit [Remote host closed the connection]
the_lanetly_052 has joined #osdev
<kazinsal> RISC-V ISA extension codes are at least more comprehensible than Cisco IOS version codes
<kazinsal> you can look up what a RISC-V ISA extension code means. a Cisco IOS version code requires three CCNPs and a cardinal with at least half a litre of holy water
the_lanetly_052 has quit [Ping timeout: 256 seconds]
xenos1984 has quit [Ping timeout: 240 seconds]
eddof13 has joined #osdev
xenos1984 has joined #osdev
sonny has joined #osdev
sonny has left #osdev [#osdev]
<gorgonical> so not exactly sure how the allwinner boot process applies to the D1, since it doesn't have a supervisor mode
<gorgonical> it uses the same ARM-y boot sequence of the firmware, spl, bootloader, OS (but with riscv names) except there's no middle point. the D1 only has machine mode and user mode
Belxjander has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<geist> i think the D1 is a particular outlyer
<geist> specifically the C906 core which seems to be particularly nonstandard
Electron has joined #osdev
ElectronApps has quit [Ping timeout: 240 seconds]
ElectronApps has joined #osdev
Electron has quit [Ping timeout: 240 seconds]
C-Man has quit [Ping timeout: 256 seconds]
Belxjander has quit [Ping timeout: 240 seconds]
myon98 has quit [Ping timeout: 265 seconds]
GeDaMo has joined #osdev
gog has joined #osdev
myon98 has joined #osdev
NeoCron has joined #osdev
milesrout has quit [Remote host closed the connection]
milesrout has joined #osdev
<not_not> Hey hey
<ThinkT510> straw straw
<not_not> Cola cola
<not_not> Bah im at the insane asylum
<bslsk05> ​'They're Coming To Take Me Away, HA-HAAA!' by Napoleon XIV - Topic (00:02:13)
<gog> so for some reason clang in PE-target mode doesn't respect __attribute__((sysv_abi))
<gog> probably because it's in PE mode i guess
<gog> so i had to hand-write a thunk to call my loader shim entry
<gog> this code is bad
<gog> ¯\_(ツ)_/¯
<gog> good news is i now have native UEFI loader, no gnu-efi dependency except for the headers
<not_not> What exactly is uefi?
<gog> firmware interface
<j`ey> unified and extensible
<gog> ^
C-Man has joined #osdev
<not_not> Ahh ok
<gog> i use it so i don't have to get into long mode myself and load files from a FAT disk
<gog> also it sets up a framebuffer which i will also need at some point
<GeDaMo> I read 'unified' as 'unjustified' :|
<gog> it could also be that
<not_not> Oh ye im still stuck trying to get into long mode
<gog> you'll need a proper GDT and a bunch of paging structures to get there
<not_not> Do bios come qs rom?
<gog> qemu? yeah it uses seabios by default
<not_not> Looking to orotect my biod
<not_not> Bios, paranoid about bios
<gog> well if you're paranoid UEFI isn't for you
<not_not> Yeah
<gog> at least any UEFI firmware that isn't OVMF
<gog> you can get the source of OVMF and see for yourself that it's shady
<not_not> Like i dont like firmware
<not_not> Ya
<gog> the others you can't know what type of shade they're up to
<not_not> The insane asylums ssl proxy is shady as fuck
<not_not> Wow 666 unread messages
<not_not> Mann i miss shady grove
<gog> what's shady grove
<zid> goog
<zid> when are we pair programming my x86 dynarec
<bslsk05> ​'Q̰ṵḭc̰k̰s̰ḭv̰ḛr̰ Messenger S.-- ̰S̰h̰a̰d̰y̰ Grove--1969 Full Album' by MazNour II (00:43:22)
<not_not> Thats shady grove
<gog> zid: wha?
<zid> you heard me
<gog> idk anything about dynarec i'm afraid
<zid> me either, but how hard can it be
<gog> seems like it'd be pretty tricky
<zid> emulate it, spit out machine code instead of updating a struct, when you get to a branch you start a new block
<zid> with a reverse lookup for original offsets to new offsets
<gog> hm
<GeDaMo> I wonder if you could use something like a binary regex to match instruction sequences
<zid> I mean, a regex is just a parser
<zid> an emulator is just a machine code parser
<GeDaMo> Yeah
<zid> so it's just a matter of implementation detail
<zid> I wouldn't *want* to use a regex for x86, but for mips/arm it probably functions
<gog> yeah seems easier with fixed-length encodings
<GeDaMo> You'd still have to match against bit masks in instructions because of e.g. register numbers
<zid> it'd still be enourmous though
<zid> you'd need to write out the entire tree of submatches
<zid> and what would the output even look like, given you're dealing with capture groups as your output
<GeDaMo> What does a dynarec normally do? Lookup tables?
<zid> do for what
<GeDaMo> Instruction matching / translation
<zid> big switch, usually, same as any other emulator
<zid> unless it's mips/arm and you can do big batches
<zid> x86 you will definitely need a couple state machines and switches
<zid> while(1){ byte = *ip++; if(byte == 0x66) {continue; size = long; } if(byte == 0x4783) { selector = cs; continue; } switch(byte){ case 0x74: /* memory read opcode */ mov emit("MOV RAX, [%x]\n", ADDR(selector, *ip++)); break; ...
<zid> something like that
<GeDaMo> "if(byte == 0x4783)" that's a big byte :|
<kingoffrance> thats a c89 byte!
<kingoffrance> the modern are "fun size" :/
<kingoffrance> its always "fun" to shrink your candy
<GeDaMo> The first byte on x86 tells you if you need to read more bytes or if the instruction is complete so that might be a useful split
<GeDaMo> I think I would use a lookup table rather than a switch
<GeDaMo> What so you want to translate x86 to? Or do you want to support multiple targets?
ravan has quit [Read error: Connection reset by peer]
ravan has joined #osdev
<gog> or is this dynamic x86->x86 recompilation?
<gog> like runtime optimization type stuff
<gog> which i do have an interest in
<GeDaMo> Instructions which implicitly use registers are a bit of a pain
<gog> true
ravan has quit [Read error: Connection reset by peer]
ravan has joined #osdev
joe9 has joined #osdev
ravan has quit [Ping timeout: 256 seconds]
ravan has joined #osdev
srjek has joined #osdev
ravan_ has joined #osdev
ravan has quit [Ping timeout: 245 seconds]
Burgundy has quit [Ping timeout: 240 seconds]
kkd has quit [Remote host closed the connection]
wxwisiasdf has joined #osdev
<wxwisiasdf> hi
<jimbzy> Howdy
<wxwisiasdf> does anyone know how can i use the DAT on System/Z ?
not_not has quit [Ping timeout: 240 seconds]
mxshift has quit [Ping timeout: 250 seconds]
ggherdov has quit [Ping timeout: 250 seconds]
ggherdov has joined #osdev
mxshift has joined #osdev
haliucinas has joined #osdev
bliminse has quit [Quit: leaving]
divine has quit [Ping timeout: 260 seconds]
divine has joined #osdev
[itchyjunk] has joined #osdev
ElectronApps has quit [Remote host closed the connection]
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
the_lanetly_052 has joined #osdev
Coldberg has joined #osdev
C-Man has quit [Ping timeout: 256 seconds]
<gog> lunch pasta
<wxwisiasdf> yes
<zid> I also just had lunch pasta
<zid> spagbol
X-Scale has quit [Ping timeout: 240 seconds]
<gog> nice
<zid> I was out of bag spol
<wxwisiasdf> no maccarroni :(
X-Scale has joined #osdev
<zid> not american enough for mac
<wxwisiasdf> hmmm, what about pineapple and spaghetti
<zid> gog: have you seen my nice white jacket with the long sleeves
<gog> yes but i'm wearing it out to dinner tonight
<zid> I wasn't aware of any combined mental asylum and restaurant establishments
<gog> i'm a regular
<zid> I'm confused about the causality here though, does the pineapple and spaghetti make you mental, or is it the other way around
<mrvn> I think parsing x86 must be the worst. You have to read each prefix byte to decide if the opcode finally starts or not and how much payload the opcode will have. Every byte is a branching point.
<mrvn> zid: that is the question, isn't?
<mrvn> zid: and if so how many exposures? Is it accumulating? Does it fade with time?
<wxwisiasdf> mrvn: if you think x86 is bad prepare to see itanium
<zid> I personally enjoy doing my own instruction scheduling
<mrvn> isn't that totaly fixed size?
<wxwisiasdf> every instruction is variabe & parallel
<zid> it's vliw that can have embedded nops
<zid> and it executes them three? wide or something hence the nops
<mrvn> Something like 256 bit with a bunch of opcodes combined.
<wxwisiasdf> yah
<zid> so if you need a bus lock you just put nops into the other channels
<mrvn> And opcodes can't depend on each other, hence the nops.
<wxwisiasdf> parallel moment
<mrvn> Seems absolutely trivial to parse.
<zid> It's easy to parse it's just the output makes no damn sense after you've done it ;)
<zid> "wtf is a movlwvwoubu.w"
<wxwisiasdf> handwritten itanium assembly... my respects
<kingoffrance> "Every byte is a branching point" what, so mel won out?
<mrvn> On x86 you also have to catch cases where the prefix encodes an opcode longer than 15 byte and is illegal.
<wxwisiasdf> no wonder why kvm is extremely fast compared to intepreters
<wxwisiasdf> especially with that isa nerfing everything
<zid> the main issue with interps is just the pure number of branches
<mrvn> wxwisiasdf: are you an intanium opcode? :)
<wxwisiasdf> probably :)
<bslsk05> ​zem.fi: The Opcode Quiz | 2014-04-05 | zem.fi
<mrvn> Caching the decoding on x86 must already give you a huge boost.
<wxwisiasdf> still, tcg and kvm have huge differences, and that is to add that tcg does indeed perform jit
<wxwisiasdf> but even with jit it plain out sucks on performance
<wxwisiasdf> albeit i want to say that s/390 has one of the best instruction encodings ever
<mrvn> m68k was nice
<wxwisiasdf> m68k 0.0001 nanoseconds after intel exists: *dies*
xenos1984 has quit [Read error: Connection reset by peer]
<wxwisiasdf> i still wonder why IBM choose intel over motorola
<GeDaMo> I don't think the 68K was ready
<mrvn> and 8088 wa?
<mrvn> was?
<gog> 8088 8088 8088 snare drum clap
<GeDaMo> "IBM considered the 68000 for the IBM PC but chose the Intel 8088 because the 68000 was not ready" https://en.wikipedia.org/wiki/Motorola_68000
<bslsk05> ​en.wikipedia.org: Motorola 68000 - Wikipedia
<wxwisiasdf> damn
<wxwisiasdf> two things that have wrong timing, CP/M and m68k
<wxwisiasdf> truly unfortunate
<bslsk05> ​spectrum.ieee.org: The Inside Story of Texas Instruments’ Biggest Blunder: The TMS9900 Microprocessor - IEEE Spectrum
<mrvn> And then Comodore realy screwed up the Amiga
<wxwisiasdf> and they both died
<GeDaMo> Mac, Amiga and Atari ST all used the 68K
<GeDaMo> Also some Unix machines
<GeDaMo> Didn't Next use it too?
<mrvn> They had Unix for the Amiga2000
<kingoffrance> GeDaMo, yes
<GeDaMo> It's not like the M68K wasn't popular :P
<wxwisiasdf> unix was everywhere
<kingoffrance> and atari jaguar :)
<wxwisiasdf> actually - unix is everywehre
<GeDaMo> "In the first half of 1978, Intel already had production-released samples of the 8088. By the end of 1978, Motorola’s 68K was still not quite ready for production release."
<wxwisiasdf> ah well
<mrvn> Imagine a superscalar, out-of-order, pipelined m68k with 64bit extension. *dream*
<wxwisiasdf> we can get that if we have a time machine and we move a chair by several inches in the year 1980
<GeDaMo> So that Intel hurts itself while trying to sit down? :|
<wxwisiasdf> yes
<GeDaMo> Changing history through slapstick comedy ... it's an interesting idea
<gog> ok but when we're done with that i have something that needs butterfly effecting
<kingoffrance> https://en.wikipedia.org/wiki/Intel_4004 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
<bslsk05> ​en.wikipedia.org: Intel 4004 - Wikipedia
<kingoffrance> basically you need to trip that "unnamed woman"
<jimbzy> You know, I heard a really good time travel joke tomorrow.
<wxwisiasdf> well for that it's easy, just remove the entire continent of america so it never happens
<mrvn> jimbzy: but it was only funny yesterday.
<jimbzy> Ya
<wxwisiasdf> time travel OS when?
knusbaum has quit [Ping timeout: 240 seconds]
<mrvn> I'm building a time machine but I'm still waiting for future me to bring me the plans.
knusbaum has joined #osdev
<wxwisiasdf> mrvn: nice paradox
<kingoffrance> wxwisiasdf, its covered in there https://www.youtube.com/watch?v=5IUj1EZwpJY
<bslsk05> ​'The Only Unbreakable Law' by Molly Rocket (00:53:25)
<kingoffrance> you can thank GeDaMo for discovering this
xenos1984 has joined #osdev
<wxwisiasdf> ah
<GeDaMo> I found it on Reddit :P
<bslsk05> ​'The 2 Crows - TimeSplitters: Future Perfect' by AbsoluteVideoGames (00:01:56)
<mrvn> kingoffrance: does he ever get to the point?
<kingoffrance> no, he's like me
<mrvn> Should I skip to 50 minutes in to hear the law?
<bslsk05> ​en.wikipedia.org: Conway's law - Wikipedia
<GeDaMo> "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
MiningMarsh has quit [Ping timeout: 252 seconds]
dude12312414 has joined #osdev
freakazoid343 has quit [Ping timeout: 256 seconds]
freakazoid12345 has joined #osdev
heat has joined #osdev
MiningMarsh has joined #osdev
Osm10 has joined #osdev
mahmutov_ has joined #osdev
mlombard has quit [Ping timeout: 252 seconds]
mlombard has joined #osdev
Osm10 has quit [Quit: Client closed]
kingoffrance has quit [Quit: Leaving]
bleb has quit [Ping timeout: 240 seconds]
gorgonical_ has joined #osdev
Burgundy has joined #osdev
k8yun has joined #osdev
pretty_dumm_guy has joined #osdev
k8yun has quit [Ping timeout: 250 seconds]
k8yun has joined #osdev
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
knusbaum has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
MiningMarsh has joined #osdev
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
<geist> wxwisiasdf: hmm dunno, but sounds interesting
srjek has quit [Ping timeout: 240 seconds]
knusbaum has joined #osdev
<zid> GeDaMo: Linux kernel exists as a nice counter-example though, where they've taken the source tree, and designed an organization to match it
<zid> subsystem maintainers, etc
<mjg> :)
<GeDaMo> But how did the source tree organization come from?
<GeDaMo> Eh, where :P
<zid> How the code 'aught' to be written, imo
<zid> ought*
<zid> it may calcify from *here*, but I don't think it has happened
MiningMarsh has quit [Ping timeout: 240 seconds]
<geist> oh just grew over time
<geist> but there was precedent anyway since other kernel source trees have existed
<zid> nobody's department is fighting for funding or at risk of getting fired if their directory gets renamed though, at least I hope so :p
<zid> aka a perverse incentive
<mrvn> zid: isn't the source the organization and the people the structure it designed? :)
<geist> seems related to the whole adage about 'shipping the org chart'
MiningMarsh has joined #osdev
MiningMarsh has quit [Ping timeout: 256 seconds]
MiningMarsh has joined #osdev
MiningMarsh has quit [Remote host closed the connection]
MiningMarsh has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
<heat> geist, I think it's pretty unique compared to other unix sources (that just do usr/, sys/, like in the filesystem)
<mrvn> usr is a relict from when harddisk where too small
<heat> definitely not a classic unix source layout a-la BSD or svr4
MiningMarsh has joined #osdev
<geist> well, that's because the BSDs also have user space code
<geist> so they generally put all of the user stuff in some sorto f mirror of the fs, but then thekernel is in sys
<geist> so you can kinda think of the linux source as being the sys/ dir in a BSD tree
<heat> good point, but the linux kernel's layout still differs from other nixes's sys/ pretty heavily
<heat> freebsd's sys/ is a bunch of misc directories slapped together
<geist> sure
<geist> a questioni s what does minix look like, since linus was kinda following that for a while
<bslsk05> ​gdevic/minix1 - Original Minix 1 sources from the book "Operating Systems: Design and Implementation" 1st ed. (115 forks/216 stargazers)
<heat> minix 1 looks pretty similar to the linux kernel
<heat> minix 3 looks kind-of-similar but it got bsd'd over time
<geist> yah so that's probably where the source layout got inspiration from
<heat> nitpick: there are 7 net* directories, but none of them are inside actual net/
<heat> (in bsd)
wootehfoot has joined #osdev
<geist> yah probably just age there
<geist> since that layout goes back probablky 40 years
k8yun_ has joined #osdev
heat has quit [Remote host closed the connection]
k8yun has quit [Ping timeout: 252 seconds]
GeDaMo has quit [Remote host closed the connection]
gorgonical_ has quit [Ping timeout: 240 seconds]
wootehfoot has quit [Read error: Connection reset by peer]
srjek has joined #osdev
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
MiningMarsh has joined #osdev
MiningMarsh has quit [Remote host closed the connection]
dund33 has joined #osdev
<dund33> Does someone have any info on stack layout when passing a struct by value to asm? (C -> x86ASM)
<dund33> QEMU memory explorer shows some random data at esp and down the stack.
<mrvn> dund33: what arch and calling convention?
<dund33> SystemV x86
<dund33> also some random data in the registers, so it's not passed through there
<bslsk05> ​en.wikipedia.org: x86 calling conventions - Wikipedia
<mrvn> I think sysV is stdcall
<mrvn> are you sure the struct is passed by value?
<dund33> Well kind of
<dund33> Did rust extern "C" call
<dund33> passed with ownership
MiningMarsh has joined #osdev
<mrvn> wouldn't that pass a reference? how can you own if you get a copy?
<mrvn> If both stack and registers don't hold the value then maybe the assumption that it is passed by value is wrong.
<mrvn> just saying. :) ....
<clever> id say read the ASM that rust generated
<dund33> Method signature is extern "C" fn foo(arg: T), with T implementing Copy and Clone, does that actually do allocation and pass a reference? I'm a bit confused rn
<j`ey> that passes by value
<dund33> yes and yet there is no sign of T on the stack or in regs
<mrvn> Have you tried with a simple T with nice recognizable numbers?
<dund33> yes
<dund33> all were u32 so i assigned them 1..n
<mrvn> try a C function pasing a struct.
<geist> if it's a reasonably large struct then it should pass a pointer to a copy on the stack
<j`ey> dund33: is it #[repr(C)]?
<geist> vs being in-line in the arg slot
<mrvn> should as in "performs better" or "the ABI will do that"
<mrvn> ?
<geist> abi will do that
<geist> but i dont know the precise rules on the x86-32 abi about when structs are expanded and passed as pointers
<geist> usually there's some size constraint
<dund33> j`ey: yes and packed
<geist> though i say all this.... perhaps structs were passed purely inline in the stack on stack based arg machines.
<geist> lets see what godbolt does
<mrvn> geist: if the struct is passed on the stack anyway then it makes no sense to create a stack copy and pass the address. That just takes 4 extra bytes.
<mrvn> unless the stack is so big that SP relative addressing couldn't get at other args anymore.
<dund33> godbolt keeps refusing to compile rust code to 32-bit ASM
<geist> mrvn: this is true
<mrvn> dund33: do you really need to support x86 32bit? That arch is kind of dead.
<geist> yah you're right, disregard: https://gcc.godbolt.org/z/9avcEncv7
<geist> it just shoves it in line on the stack
<geist> been a while since i seriously thought about stack based arg passing
<geist> and alas nothing on godbolt does 68k it seems
<dund33> u actually worked on Amigas?
<mrvn> Still have some
<dund33> noice
<dund33> ok will dig into making this pile-of-trash os of mine 64bit
<dund33> thx for help
dund33 has left #osdev [#osdev]
the_lanetly_052 has quit [Ping timeout: 256 seconds]
<geist> hmm i wonder how aignment affects things
<mrvn> geist: padding args on the call stack?
<mrvn> are sse regs passed on the stack too?
<mrvn> or fpu even
<geist> i thought x87 at least had it's own arg passing scheme
<mrvn> x86 has too many calling conventions.
<moon-child> indeed
<moon-child> even 64-bit x86 has two
bauen1 has quit [Quit: leaving]
<geist> that's whatcha get when you're still around 45 years later
<mrvn> pi: pi.cc:74: int64_t ArcTan<m, x>::extend(int64_t, int64_t) [with long int m = 16; long int x = 5; int64_t = long int]: Assertion `series.begin() != series.end()' failed.
<mrvn> *sigh*
<mrvn> My infinite series isn't infinite
<moon-child> geist: idk, I think there's actually less fragmentation now
<mrvn> moon-child: 2 < 15
<moon-child> geist: like, insofar as there are multiple c compilers, they interoperate. And non-c languages tend not to care about abi
<geist> sure
<geist> from what i had seen, MIPS really had trouble with ABI fragmentation
bauen1 has joined #osdev
<geist> but no one talks about it anymore for obvious reasons
<mrvn> moon-child: All non-c languages I know have an extern "C".
<moon-child> mrvn: right, which interoperates with their platform c abi
bleb has joined #osdev
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
knusbaum has joined #osdev
wxwisiasdf has quit [Quit: leaving]
knusbaum has quit [Client Quit]
knusbaum has joined #osdev
kkd has joined #osdev
rustyy has quit [Read error: Connection reset by peer]
rustyy has joined #osdev
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
knusbaum has joined #osdev
k8yun__ has joined #osdev
k8yun_ has quit [Ping timeout: 240 seconds]
k8yun__ has quit [Remote host closed the connection]
k8yun__ has joined #osdev
k8yun_ has joined #osdev
k8yun__ has quit [Ping timeout: 256 seconds]
k8yun_ has quit [Read error: Connection reset by peer]
k8yun_ has joined #osdev
<gog> mew
* kazinsal headpats gog
* gog prrrs
<mrvn> What do I need to use to have the string literal UDT? https://godbolt.org/z/615P5Yf8o
<bslsk05> ​godbolt.org: Compiler Explorer
<mrvn> ahh, forgot using namespace std::literals