<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)
<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? :)
<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]
<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
<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.
<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]
<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>
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