<sortie>
Meanwhile I patched my 80 ports and fixed a ton of these issues and it actually cross-compiles cleanly now, with maybe a few latent bugs leaking the host environment that I didn't realize yet since it's minor
<sortie>
heat: That behavior is dangerously **wrong** and must be fixed.
<dh`>
cmake is a law unto itself
<dh`>
good luck fighting with it, let us know how many windmills you score
<graphitemaster>
sortie, there is more than one way to skin a cat, the only constant is cats will be skinned
<sortie>
I like the alternative phrasing “there's more than one way to pet a cat”
<sortie>
Most people are not able to coherently communicate two distinct ways of skinning a cat
<graphitemaster>
the visceral imagery of skinning a cat is more conducive to the horrors we do in software to make things work
<sortie>
fool I am the cat(1)
<gog>
mew
<zid>
Out here in the fields
<zid>
I fight for my meals
<graphitemaster>
The scarecrow got a raise because he was out standing in his field
<gog>
if he gets a promotion he'll be a stuffed suit
mctpyt has joined #osdev
sonny has quit [Ping timeout: 240 seconds]
sonny has joined #osdev
<graphitemaster>
sortie, is `cat cat(1) cat(2)` cat(1)cat(2) or cat(12)
<gog>
i'm cat 6
vdamewood has joined #osdev
sonny has quit [Ping timeout: 250 seconds]
mctpyt has quit [Read error: Connection reset by peer]
ElectronApps has quit [Remote host closed the connection]
<gog>
fun fact, if you don't pop the registers in the same order you push them your isrs are gonna fuck up
mahmutov has joined #osdev
<sham1>
Tell me more
<gog>
that's all the fun facts i have today
<Bitweasil>
"How to annoy interviewers asking you to swap two registers using a temp register in one easy trick." ;)
<Bitweasil>
push rax; push rbx; pop rax; pop rbx
<gog>
haha
<Bitweasil>
For years I've answered the "How would you tell how many bits are set in this register?" question with "POPCNT. Or whatever your local population count instruction is." "Haha, ok, yeah... now, if you don't have that, write code to do it."
<Bitweasil>
(there are "clever" options, and I just bang out a for loop, hasn't been a problem yet)
<GeDaMo>
I remember a page which tested the options, I think a table lookup was the fastest
<kingoffrance>
^ this is why hackers delight was a good book. "it varies"
orthoplex64 has quit [Remote host closed the connection]
orthoplex64 has joined #osdev
Dreg has quit [Read error: Connection reset by peer]
heat has joined #osdev
<heat>
sham1, i know i'm super late but popcnt isn't part of the base x86_64 instruction set
<heat>
neither is movbe
<sham1>
Indeed. Haswell has it though, and that's good
superleaf1995 has joined #osdev
<superleaf1995>
I have a question
<sham1>
And that is indeed why those instructions aren't used without march
<superleaf1995>
What are the essential tools one should have to attract people to port their OSes to another architecture
<superleaf1995>
aside from the obvious gcc/binutils
<heat>
mind control
<superleaf1995>
and also aside from the, also obvious, bootloader multiboot2/stivale2; and aside from a barebones tutorial
<superleaf1995>
heat: or total world domination? :)
<GeDaMo>
Free cheese! :P
<j`ey>
good simulator/emulator
<kingoffrance>
^
<heat>
obviously if you have mind control you'll skip the easy world domination and make people adopt your OS
<heat>
when you conquer the world with your OS you've gotten your world domination victory but the intended way
<superleaf1995>
j`ey: yeah we can say that one is done
<heat>
so realistically: no one is ever going to port your OS to another architecture unless you've made it
<heat>
99.9% of all projects here are just single person projects
<superleaf1995>
right now i am trying to get people using 390/zArch; i made a bootloader called flatboot which supports stivale2, made a barebones tutorial, made some documentation, cooperated with the pdos author to decipher some "unknowns", helped refine some build processes (specially for the cross gcc thing) and hercules-hyperion already emulates stuff good
<heat>
or in the best case, projects that atract a random contributor or two which submit a port
<superleaf1995>
true..
<sham1>
Of course with mind control, you also get world domination as well
<superleaf1995>
heat: i don't mean port **my** os
<superleaf1995>
i meant getting people interesting into porting **their** os into z/arch
<sortie>
superleaf1995, just give such hardware away for free to kernel, toolchain, and ports people
<heat>
that's another question, but honestly I feel like you're screwed either way
<GeDaMo>
Can I actually buy some 390 hardware for a reasonable price?
<superleaf1995>
micro 390's exists
<sortie>
superleaf1995, seriously, if the right people have a free device to play with, they really might
<heat>
most projects struggle to support the 3-4 main architectures (x86(_64), arm(64), riscv(64))
<superleaf1995>
well on the 390 world we have some outdated gcc ports for mvs3.8j
<sham1>
Make a Lisp of some kind, and some crazy person will port it to whatever device they have left over
<superleaf1995>
you can use gcc on z/os but it costs like 1 billion dollar
<sham1>
Or a Forth
<superleaf1995>
ah
<heat>
do you have linux support? that's your first step
<superleaf1995>
yes
<heat>
you've made it then
<heat>
congrats
<superleaf1995>
but it can only run under a proprietary vm iirc
<superleaf1995>
a m inside a z/arch machine
<sham1>
Of course the true ideal is a custom OS on a custom architecture on a custom chip made from custom transistors made from custom sand
<superleaf1995>
z/os needs to run z/linux on a virtual machine, but z/os runs on the real thing
<heat>
well, making linux run on your thing is the first step
<superleaf1995>
the only way to go the "free" route is either use z/PDOS or MVS/CE
<heat>
then you add glibc/musl support in the libc (if you need to, that is, pretty sure they have s390 support)
<superleaf1995>
heat: linux does run but z/arch is mostly an unexplored field outside of hobby stuff
<heat>
then explore it
<heat>
checkmate atheist
<superleaf1995>
the only hobby os rn is z/pdos
<superleaf1995>
and my os :p
<heat>
if you're concerned about the architecture not getting adoption in general, the first step is to port the linux kernel; if you're converned about the arch not getting hobby OS support, you're screwed
<superleaf1995>
well - i'll keep documenting stuff so hopefully one day we have tutorial-os on z/arch
<superleaf1995>
heat: alright
<GeDaMo>
Are there FPGA implementions of the z/architecture?
<heat>
superleaf1995, unfortunately most hobby OSes are either x86 only or arm only for your ocasional raspberry pi
<heat>
not much diversity on that end
<heat>
OTOH if you want to you can port your architecture to my OS (*shameless plug alert* https://github.com/heatd/Onyx)
<bslsk05>
heatd/Onyx - UNIX-like operating system written in C and C++ (2 forks/19 stargazers/MIT)
<heat>
i'll take anything that's kind of relevant
<heat>
:D
C-Man has joined #osdev
Coldberg has quit [Ping timeout: 256 seconds]
<kingoffrance>
that's not wrong. "port your architecture to my OS" that's another way of looking at it
<geist>
superleaf1995: i thought you were big into riscv a while back, or was that someone else?
<superleaf1995>
I did
<superleaf1995>
i dwelved into risc-v but i found it unappealing to me
<superleaf1995>
mostly because it was just embedded stuff
<geist>
also didn't we kick you for some reason?
<superleaf1995>
no?
<geist>
or was that someone else that was into riscv and had a long name
<geist>
kk. i think it was someone else
<superleaf1995>
i was the guy who asked about pci and stuff
<geist>
there was someone in on #osdev maybe 18 months ago that had a long nick like yours, did a bunch of riscv stuff, and was generally engaging and then would just randomly go on a racist tirade
<superleaf1995>
wasn't that skyz?
<geist>
no skyz just wont stop blathering
<geist>
i figure he'll grow up in a few years
<geist>
and yeah i remember that you were building the PCI configuratio thing. got it
<superleaf1995>
yeah and i dwelved a bit too much onto it
<geist>
haha
<geist>
well, i recently got around to doing much of the same thing
<superleaf1995>
"lemme do the work of the bios and manage the power control of the pci bus" :p
<geist>
though i haven't yet written the actual BAR assignment stuff, but its needed for ARM and riscv qemu at least
<superleaf1995>
bar assignment is horrible with bridges
<geist>
so i was thinking back to what you had been doing at the time
<geist>
yep!
<superleaf1995>
i liked risc-v; sadly one can't just havea ficticious OS that won't run on real hw
<superleaf1995>
so i just threw my progress into the garbage can
<superleaf1995>
now i am here, writing an OS+bootloader for machines only used by big $$$ banks or scavengers
<superleaf1995>
[have yet to test on realiron, but it's getting there btw]
<klys>
should have bought the k210 sipeed board
<geist>
yah i mean i'm all for hacking on esoteric hardware, but what's the idea behind writing your OS/etc on IBM stuff?
<superleaf1995>
geist: because nobody else would
<geist>
okay. sounds good
<superleaf1995>
except the z/PDOS author, so i tought "well, if i am going to do something it better be helping out the whole mainframe hobby scene"
<geist>
my only real point here is you have far more capability to have a real riscv machine than an IBM mainframe
<superleaf1995>
micro 390s exists, and some people have offered to ipl my os on the real thing
mahmutov has quit [Ping timeout: 240 seconds]
<geist>
okey dokey. funny i was actually thnking of getting a linux account on a ibm virtual machine
<bslsk05>
www.theregister.com: You've got OpenSolaris in my System z • The Register
<kingoffrance>
well the PDOS guy stopped by once (maybe back on *node) ... i like the public domain and the c89...but what interests me may likely repel others :)
<CompanionCube>
can't you already boot them without qemu under PVH?
<CompanionCube>
just not with PCI devices it seems
<klys>
it looks like the "standalone" binary is /usr/libexec/xen/boot/pv-grub-x86_64.gz which is a gzipped ELF 64-bit LSB executable, x86_64, version 1 (SYSV), sttically linked, with debug_info, not stripped
<CompanionCube>
iirc xen on arm *only* does PVH
<klys>
now if I could just get a handle on how to run that binary
<klys>
I suspect something like "xl create" except I've looked far and wide and no one has a xl.cfg file for me.
<klys>
yes that's xen not qubes, so I'm unsure how to get the video
<CompanionCube>
ah
<klys>
the device model for an hvm is started by another standalone, /usr/libexec/xen/boot/ioemu-stubdom.gz which is the same kind of file
<klys>
to be clear: the device model is vm-dm and shows up first in xl list;
<klys>
it runs qemu for the hvm
* CompanionCube
doesn't know much about how qubes is set up
<klys>
I have had some success running the tool to get the display for the vm
<klys>
I had to go in and modify the qemu commandline in the rootfs for the stubdom
<klys>
so if I don't put it back, my machine won't start up properly if I reboot :)
<klys>
by stubdom in this context I mean the kernel running in the device model vm-dm
biblio_ has joined #osdev
<sham1>
Companion Qube
<sham1>
A container that follows you around and does not threaten to stab you
<klys>
so, I think qubes relies on the linux kernel to communicate with the qubes-guid program
<klys>
which stands for gui daemon
xenos1984 has joined #osdev
<klys>
after starting the vm with virsh at dom0, I then have to run that program to get the window.
Lugar has left #osdev [Leaving]
biblio has quit [Ping timeout: 250 seconds]
<klys>
one problem is virsh never terminates, another problem is the vm numbers from xl list; are ever increasing.
<klys>
sham1: stab: symbol table
biblio_ is now known as biblio
<sham1>
I prefer to have DWARFs working for me
<kingoffrance>
i believe he previously accepted tempest 2000 companion cube as an acceptable interpretation, so i am also ok with this new qube as it seems back-compatible
<kingoffrance>
i dont see any breaking API change, merged