<zid>
not something to genuinely strive for because it's so useful
<heat>
here's some food for thought: unified doesn't mean open
<heat>
is UEFI open? (spoiler: no)
<heat>
is x86 open? (spoiler: absolutely not)
<kof123>
is openvms open?
nyah has quit [Quit: leaving]
<heat>
Is OpenBSD open?
<heat>
*illuminati all seeing eye*
<zid>
There are presumably 0 open bioses for x86 now
<kof123>
*eyes <shakes head>
<heat>
zid, depends on what you mean by open and BIOS
<heat>
seabios and OVMF are open in every sense of the word
<heat>
coreboot is open in only some sense of the word, varying per platform
<heat>
if you boot blobless on your x86 processor (the best case coreboot scenario) you still have another 7 or 8 coprocessors that aren't, right there in your board
<epony>
"open up all the things" --theSauron
<epony>
reprogrammability will help solve these challenges
<epony>
nothing impedes that other than proprietary control and monopolistic system designs
<epony>
so it's a self-stabilising problem, mostly (optimism and more progress in standardisation that is reprogrammable / reconfigurable)
<epony>
openness comes with access, access to the programming model.. solves it
<heat>
you know, I think that in a way, the more standardized something is, the less open it is
<epony>
there are open and free standards
<epony>
and there is closed and proprietary implementation even without standards, it's just incompatible and thus limited use
<heat>
sure, you can do SBI calls in riscv to do IPIs, arm the timer, etc, fully standardized. is it more open than x86?
<bslsk05>
en.wikipedia.org: Soft microprocessor - Wikipedia
<epony>
eventually designs improve..
<epony>
and these get "affixed" in high-performance implementation in mass production
<epony>
technically it is open (to the design and production business units)
<epony>
not for the clients and reimplementers
<epony>
at some time, saturation of the market is reached, no more exploitative sales of incomplete or limited or partial programmability is acceptable, and more opening happens
<epony>
it can be sped up with regulation and steering
<epony>
it can be cracked open 40 years ago
<epony>
it's not a very tough nut..
<epony>
it is an artificial inefficiency / defect in design
<epony>
businesses demand it
<epony>
users hate it strongly
<epony>
re-implementing different internals that provide the same instruction specification is "a way at it"
<epony>
fabless provides that capability long available now
<epony>
architectures have "licensees" and re-implementers
<epony>
lack of standardisation is the single most inefficient challenge in engineering, it happes from simple machines and their specification parameters to complex machines
<epony>
standardisation is opening it for reimplementation
<epony>
non-standard and incompatible ever changing designs and their bundling as "unit" of compute is an anti-standardisation practice
<epony>
that's what arm reimplementers do, and that is a general engineering fault
<epony>
it's acceptable to some level in embedded and simplified (small units) but it becomes infeasible with time
<epony>
even functional blocks in microprocessors and microcontrollers have standards internally (not only externally)
<epony>
so they are interfacing inside the central computing machine in a standards and interface specified way
<epony>
no other way to achieve complex and reliable designs, technically it becomes an overly complex task to design highly coherent non-standards and non-interfaced functional blocks
<epony>
it's a main principle of engineering and machine construction and is an integral part of electronics design
xenos1984 has quit [Read error: Connection reset by peer]
<epony>
how accessible that information is, is just a matter of control and secrets of commerce and competition (artificial)
<epony>
internally these things do not exist (non-standard and incompatible interfaces, just a different component is used which matches or is re-imlpemented anew)
<epony>
this is part of the modular-composable machinery construction
<epony>
it's efficient and reliable, when done well
<epony>
it can be done without the business obstruction to its propagation and use
<epony>
eventually, it is needed to unblock progress and improvements industry wide in a class of components and machine elements
<epony>
design for standards is happening all the time
<epony>
when there is no standard, one is invented by the implementers as a specification or a de-facto standard and traded around as a licensed technology etc
<epony>
access to that to a broader audience of programmers and software implementers is then a business decision too
<epony>
with a standard and reference implementation, that is open and free / public access, it's not that important who manufactures it, but how well and how reliable / efficient / affordable / mass-scaled / compatible
<epony>
these are the properties needed by programmers and other engineers
<epony>
SoC are not that much different but they hide their internals and do not standardise these for competitive reasons not because it is not important and not needed, it is a real problem
<epony>
the more complex the functional blocks in the microprocessors and integrated semiconductors become, the more it is needed
<epony>
and withheld for commercial and lock-in reaons
<epony>
25-30 years (or half a career) is the aimed lock-in proprietary grab, and it's sustained between a cartel of business licensees
<epony>
only when there are no other machines a regulator steps in and hits that nut with a policy staff to crack it open
<epony>
Intel and IBM had their "nuts" addressed in that way
<epony>
AT&T too, supposedly
<epony>
the virtual machine specification are subject to similar notes of applied co-existence
<epony>
that means that byte-code / intermediate-representation are a virtual machine technology that has to have at least one open / accessible / generally free variant (or these get created)
<epony>
applies to compilers and application models too
<epony>
not only physical microprocessors and highly integrated circuits and modular-composable units of computing and communications
<epony>
it's typically sorted with arrangements and license models between big businesses or lawsuits and such dramaturgy
<epony>
crossing nations borders and regions, nothing exists from that economic-financial and legal-political reality, other than the standards, the physical units components and ther desing, manufacturing and programming models
<epony>
if leadership and technical superiority is needed in one very large super-power, it better has standards and licensees otherwise it gets surpassed by other such
<epony>
inefficiencies are only sustainable in an internal econo-political control region
<epony>
and these get challenged by international competition and cooperations of others to overcome that problem ;-)
xenos1984 has joined #osdev
<epony>
machines are after all supposed to serve humanity and not the other way.. so modularity and composability are princilpes used to improve the machines so they can offload work from the people and achieve human development that way with better results
<epony>
standardisation is a part of that
<epony>
and.. we used larger machines to design smaller machines
<epony>
that's what the mainframes were used for, so electonics simulation and desing were the primary objectives, and computation and communication are applications of that process
<epony>
at least physics and their mathematical and analytic models are standardised scientifically, then the machines are a matter of efficient modelling of these inventions and found applied use of engineering
<epony>
so there is always some "standard" understanding and reproducible designs
<epony>
efficiency requires that it propagates as much as possible into refined and elaborate recurring design and manufacturing stages
<epony>
microprocessors and other integrated electronics devices are not an exclusion, they are the most important application of these principles ;-)
<epony>
businesses are just organisational units
<epony>
better organisation solves inefficiencies
<epony>
designs improve, things move forward to better applied use of computing and communications
<epony>
sometimes there can be shor term glitches in that but their sustained inefficiency is temporary
<epony>
markets and consumption are a form of regulation too, competition and reimplementation and redesigns too
<epony>
failed machine designs are many, but overall the optimal designs are kept or reproduced
<epony>
we call that technological progress, and it produces engineering textbooks and standards
<epony>
there is always a solution to roadblocks and artificial problems
<epony>
there are standards for electronics, computer hardware, and software too
<epony>
and communications protocols
<epony>
even for industrial process and automation
<bslsk05>
en.wikipedia.org: List of computer standards - Wikipedia
<epony>
it's a very large topic, but even operating systems standardise somewhat on interfaces and organisation
<epony>
at least the better ones strive for interoperable and portable / better modelling and programming of the machines, in both languages and implementation as operating environments
<epony>
so programming languages are standardised too, and data exchange / interchange formats
<epony>
a machine that implements standards, being slightly non-standard internally is taken as a small unit of computing and replaced later with a standard one internally too
<epony>
but it's standardised, just not accessible and open, as it's comprised of functional and logic blocks with interconnects internally
<bslsk05>
en.wikipedia.org: PC System Design Guide - Wikipedia
terminalpusher has quit [Remote host closed the connection]
<epony>
and then there are international standards organisations from different reagions that provide comparable and open/free/public standards (some of these are commercial but still accessible)
<bslsk05>
en.wikipedia.org: ISO/IEC JTC 1/SC 22 - Wikipedia
joe9 has joined #osdev
<epony>
others have de-facto language standards as specifications
<epony>
you know about POSIX/SUS too
<epony>
applying these to a newer and more enthusiastic and emmerging class of machines is not only fun but really important and useful to everyone
<epony>
in the process, improving the standards and reference implementations are a net benefit too
<epony>
and compatible machine designs and classes interoperability is a result of that
<epony>
I am sure you can find some standards and quirks of programming various machinery on the osdev wiki too ;-)
<epony>
at least pointers where to go find specifications
<epony>
in my opinion, standards are not everything, but the useful parts of them are important
<epony>
therefore standardisation on machine initialisation and preparation for work is subject to standardisation too
<epony>
or at least should provider a standard machine model after that
<epony>
if the realistic / physical machines can not be standardised, at least a virtual and emulated one can
<epony>
that's the bytecode/intermediate representation/managed runtimes and their match towards an efficient model/emulation/simulation of a realistic machine on which they are running or which they will simulate with its standards
<epony>
that's also the reason why these seemingly non-tandard PC 97-01 specifications are part of the virtualisation software implementation as various "devices" and "buses"
<epony>
and also match a generation of vary popular mainstream middle class computers, which even when obsoleted are replaced as virtualisation and emulation for their programming model (that many many applications rely on)
<epony>
to the extend that new systems are realised now first in emulators / virtual machines and standards specifications now, for example the Risc-V
<x8dcc>
but for some reason I didn't think it pushed the whole register even if the arg was smaller
<zid>
You'd get something like this
<zid>
loads ax from incoming param b, pushes eax and 12, call g. Specifically doesn't push ax, pushes eax.
<x8dcc>
yes exactly
<x8dcc>
it's what I saw when trying to debug with gdb (thats why I noticed 32bit doesn't use edi and esi)
<x8dcc>
but for some reason I thought 2bytes were pushed instead of 4 :p
<zid>
Best part would be if you had truncated a pointer or bitmask or something and it still worked but behaved insanely
<ornx>
https://pastebin.com/EjhhwKhF what is happening here exactly? how is rax changed even though nothing should have modified it? or is gdb displaying incorrect information?
<ornx>
wait a second, the dec instruction starts with 0x48... i'm probably still in 32 bit mode nevermind lol
<zid>
What's cooler is that you managed to get qemu and gdb to disagree on the cpu mode
<zid>
if I do that I get big errors about the size of messages not being correct
dude12312414 has joined #osdev
<x8dcc>
I got those messages too
<x8dcc>
I had to patch gdb
<ornx>
yeah grub's multiboot2 seems to drop you into 32-bit mode unless you specify the entry address for amd64 efi mode in the header, specifically, which i guess makes sense although i thought if it was going to do that then it would complain about the 64-bit ELF
<zid>
you're supposed to compile it with xml enabled