<kazinsal>
mistress gog is the registered peak osdev mommy
<zid>
muscle mommy
<gog>
osdev barbie
<zid>
I am osdev oppenheimer
<gog>
nice
<kazinsal>
would rather be nestled into osdev oppenmommy's caring bosom
<kazinsal>
nyoron
<kazinsal>
<3
<zid>
I've always wanted to become destroyer of worlds
<heat>
i am become zid, destroyer of....
<GeDaMo>
Easier than osdev :P
<heat>
tescos?
<zid>
destroyer of functions only used in one TU that aren't marked static
<heat>
there we go
<zid>
heat is destroyer of footballers' natal clefts
<heat>
hahaha wtf
<heat>
you really had me googling there
<zid>
arse crack :P
<heat>
"Colloquially the intergluteal cleft is known as bum crack (UK) or butt crack (US)."
<zid>
I read a great quip the other day, someone kicked someone else in the arse and they were complaining how hard they'd done it and that they'd ruined their bum for life
<zid>
they replied "How bad could I really have made it? It already had a crack in it"
Left_Turn has joined #osdev
<gog>
hi i'm doing osdev today
<zid>
eww
* zid
destroys
<gog>
understandable
<gog>
this is kindof a godforsaken project
<zid>
the syscalls inside uefi one?
<gog>
ys
<zid>
never leave the embrace of boot services
<gog>
hide that you're even in boot services
<gog>
pretend like everything is cool
<zid>
sys_bootservices
<gog>
don't cry the moment somebody tries to make a syscall that isn't open(), read(), close()
<zid>
make it like an ioctl
<gog>
i'm reimplementing unix poorly in uefi
<zid>
is there any other way
<gog>
yes
<mjg>
you can do it poorly elsewhere
<mjg>
ask heat for tips
Left_Turn has quit [Ping timeout: 260 seconds]
MiningMarsh has joined #osdev
Left_Turn has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
[itchyjunk] has joined #osdev
k0valski18891 has quit [Ping timeout: 260 seconds]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
Jari-- has joined #osdev
<gog>
i want a bagel
<sham1>
why
<gog>
because i like bagel
<Jari-->
so basically -fpic does not work with static binary linking / gcc ld ?
<Jari-->
would be so good to have only relative memory pointers
<Jari-->
Program Independent Code
<Jari-->
Position Independent Code, that is
<gog>
position
<sham1>
Program Independent Code would be quite confusing
<Jari-->
If type is ‘pie’, code generation produces an -fpie executable. This results in similar optimizations as ‘exec’ except that -fpie is not disabled if specified at compilation time.
Left_Turn has joined #osdev
<Jari-->
A static position independent executable (PIE) is similar to static executable, but can be loaded at any address without a dynamic linker.12 Sept 2017
<Jari-->
I am going to use this, if this is a flat binary, not a format like .so ELF32/ELF64 etc. ?
<Jari-->
Windows DLL is using PIE:
<Jari-->
Dynamic-link libraries (DLLs) in Microsoft Windows use variant E8 of the CALL instruction (Call near, relative, displacement relative to next instruction). These instructions do not need modification when the DLL is loaded.
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
<Jari-->
well, read about -fPIE - figures, not going to use the assembly code in my LIBC, get GLIBC C language variants for everything
Harriet has quit [Quit: Client update, hang on...]
<bslsk05>
'System F - Solstice (Original Extended Mix)' by 6O47 (00:08:45)
<Jari-->
coding music I mean, of course not to disturb you too much :-) sorry
carbonfiber has joined #osdev
Maja has joined #osdev
dennis95 has joined #osdev
stolen has joined #osdev
<gog>
nya
<gog>
maybe i'll have a nap
<sham1>
Naps are good
<sham1>
Although they mess up sleep schedules
FreeFull has joined #osdev
CaCode- has quit [Ping timeout: 258 seconds]
heat has joined #osdev
heat_ has quit [Ping timeout: 245 seconds]
<gog>
meh it's saturday
<mcrod>
hi
<bl4ckb0ne>
its caturday*
<sham1>
Yes
<sham1>
Although whose?
<heat>
mine
<sham1>
Your caturday. I see
<gog>
meow
* gog
prr
<heat>
meow
<sham1>
Is the cat still on the lap
<gog>
meow mrrp prr mrrp
<heat>
no
k0valski18891 has joined #osdev
<sham1>
🐈
<heat>
but he's just made a weird noise just now
<heat>
the fucker
nanovad has quit [Ping timeout: 244 seconds]
nanovad has joined #osdev
joe9 has quit [Quit: leaving]
<heat>
the ia64 assembly syntax is horrendous
<heat>
damn
<heat>
br.ret.sptk.many is a mouthfull innit
frkazoid333 has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
ytret98 has joined #osdev
Arthuria has joined #osdev
CaCode has joined #osdev
rorx has quit [Ping timeout: 250 seconds]
opalfruit has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
elastic_dog has quit [Ping timeout: 245 seconds]
<zid>
vliw syntax is horrendous in general
Arthuria has quit [Ping timeout: 260 seconds]
elastic_dog has joined #osdev
Yoofie has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
Arthuria has joined #osdev
dennis95 has quit [Quit: Leaving]
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
zxrom has quit [Remote host closed the connection]
zxrom has joined #osdev
opalfruit has quit []
andydude has joined #osdev
joe9 has joined #osdev
<ytret98>
by any chance does anybody know which spec describes the 'Device' SATA register?
ytret98 has quit [Quit: Client closed]
terminalpusher has quit [Remote host closed the connection]
ytret has joined #osdev
rorx has joined #osdev
FreeFull has quit [Ping timeout: 250 seconds]
<mcrod>
hi
<gog>
mcrod:
<gog>
may i hug you
<mcrod>
yes
Arthuria has quit [Ping timeout: 246 seconds]
goliath has joined #osdev
CaCode has quit [Quit: Leaving]
CaCode has joined #osdev
valshaped742 has quit [Read error: Connection reset by peer]
valshaped742 has joined #osdev
<mcrod>
heat_: help!
xenos1984 has quit [Read error: Connection reset by peer]
<mcrod>
what do I do after ceaseless dragon
<mcrod>
or whatever the fuck tha tis
<mcrod>
that*
* gog
hug mcrod
* mcrod
hug gog
ytret has quit [Quit: Client closed]
[itchyjunk] has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
wblue has joined #osdev
[itchyjunk] has joined #osdev
CaCode has quit [Ping timeout: 245 seconds]
heat_ has quit [Remote host closed the connection]
CaCode has joined #osdev
wblue has quit [Quit: wblue]
heat_ has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
qubasa has joined #osdev
carbonfiber has quit [Quit: Connection closed for inactivity]
andydude has quit [Quit: Leaving.]
gareppa has quit [Quit: WeeChat 3.8]
wblue has joined #osdev
Jari-- has quit [Ping timeout: 246 seconds]
<Cindy>
hi os developers
<Cindy>
in a single-core processor, how does the scheduler pause the currently running program
<Cindy>
does it modify the program's code?
<moon-child>
timer interrupt
<GeDaMo>
The scheduler usually runs when the program calls the kernel or due to a timer interrupt
<clever>
Cindy: a timer interrupt will force the cpu to switch to an interrupt handler, which saves the current PC the program was running at
<moon-child>
periodically (every 10ms, say; can be configured), the cpu will interrupt whatever is currently running and jump to the kernel
<clever>
and then it just changes the stack pointer, and returns to the "wrong" process
<Cindy>
yeah but that requires a timer in the hardware
<Cindy>
that is hooked up to the CPU's interrupt pin
<moon-child>
historically it might have worked that way, but now it's built into the cpu itself
<clever>
win 3.11 instead used co-operative multi-tasking, where it can only happen when a process gives up control on purpose
<clever>
by calling yield() or another blocking function
<clever>
no timer to force it
<moon-child>
didn't mac os 9 work that way too?
<Cindy>
how would you do this without a timer
<GeDaMo>
Old Macs did, yes
<clever>
by writing a program to call yield() at regular intervals while its doing work
<clever>
and to call a blocking primitive when its idle
<moon-child>
Cindy: I don't know of any way to do it reliably without a timer and without inserting explicit safepoints into the program
rorx has quit [Ping timeout: 260 seconds]
<moon-child>
the latter is done e.g. by go and hotspot, but not usually by runners of native code
elastic_dog has quit [Ping timeout: 260 seconds]
<Cindy>
yeah i'm reimplementing an RTOS
<Cindy>
and the tech manual says that a real-time clock is hooked to a CPU's interrupt pin
<Cindy>
and it changes the interval via a clock driver
<moon-child>
oh for embedded it might still work that way
<moon-child>
regardless what's the issue with timer interrupts?
<Cindy>
sorry :P
<Cindy>
moon-child: nah no issue
<Cindy>
just curious
wblue has quit [Quit: wblue]
* geist
yawns
<clever>
morning?
<geist>
a late morning
<geist>
well, been up a while, just finally yawned at the channel
elastic_dog has joined #osdev
<clever>
ive been discovering more insanity in the dwc core
* sham1
yawns
<sham1>
And here it's almost midnight
<clever>
there is a global interrupt mask register
rorx has joined #osdev
rorx has quit [Client Quit]
<clever>
after a reset, reading it claims interrupts are unmasked, but a random selection remain masked (some do work)
<clever>
if you set it to unmask again, then everything works
<clever>
my theory, is that there are duplicate copies, held in each clock domain
<clever>
and after a reset, they are out of sync
<clever>
reading only returns one of them
<geist>
ah, yeah probably worth manually setting
<geist>
maybe there's some sort of 'hold the reset down some period of time before reading anything' thing?
jjuran has quit [Ping timeout: 245 seconds]
<geist>
have seen that sort of thing before
<clever>
i had a sleep, and it didnt help
<geist>
presumably so all the clock domains get a shot at an edge with reset helt
<clever>
and reset is self-clearing
<geist>
ah
<clever>
which implies it wont clear until reset is finished
<geist>
yah
<clever>
the int mask, is also in the same "write once" register as dma enable, which wasnt working before
<clever>
so i think i need to reset before i try to enable dma
<geist>
reminds me i always forgot about that age old debate when designing logic: should reset latch on the next clock edge or should it asynchronously reset thins
<geist>
it's one of thsoe depends on the situation sort of thing
<clever>
i would say, async latch
<clever>
and only clear a few clocks later, when actually done
<geist>
you'd think, but then i think complicated designs that are clocked tend to do a (posedge(clock) & reset) ... design
<clever>
so your reset pulse can be less then 1 clock long
<clever>
reset needs to be an async register, that can latch without a clock
<geist>
there are pros and cons
<clever>
and then feeds into the posedge stuff
<clever>
what about cases where the clock has been disabled for a sleep state?
<geist>
i think the problem is real world mixing async logic with sync logic, since there may be some races in there that lead to some sort of badness
<clever>
and reset is supposed to un-stick it, and restart the clock
<geist>
well, that may be where you have a part of the design that's async
<geist>
like the clock management block
<clever>
how about both, an async reset register, that can latch without a clock
<clever>
and then buffer it thru another register, that copies on every clock edge
<geist>
well, if it's a register then i think almost by definition it's clocked
<clever>
but the clock reset logic, bypasses that buffer obviously
* geist
shrugs
<geist>
i dont really know the answers, just was thinking about that. it's one of those fundamental digital design things
<clever>
yeah
<clever>
and there is likely no right answer
<clever>
depends on the use-case
<clever>
for the dwc case, reset is set over AHB, so there must be a clock coming in from the bus
<geist>
yah totally, it's literally a bit in a register so it's clearly clocked
<geist>
and then it clearing means it probably has some logic behind it that holds it for at least some number of clocks
<geist>
maybe there are some internal sram cells that need to be written out or something
<geist>
that take some number of clock cycles
<clever>
that reminds me, in the power-domain logic of the rpi, there is a "memory repair" step you have to run thru
<clever>
that feels like resetting all sram/registers to the defined default state
<geist>
yah
<clever>
functional isolation is another flag in that process
<clever>
so the core cant do funky things until after it has been put into a defined state
<geist>
for things like cache and TLB that's why ARM tends to define as completely undefiend when starting, including having trash TLB entries
<geist>
because SRAM can't be easily whacked back to zero inone clock cycle, i think
<geist>
or at least would require special sram for that
<clever>
wont that cause problems with the unexpected cache hit exception?
<geist>
it does, but it's not a problem on cycle 1 because the MMU and TLB are off, so the cpu isn't consulting those tags
<geist>
but it says you need to dump it before you enable them
<clever>
i seem to remember getting that fault, when i turned the mmu off
<clever>
but i could be mis-remembering
<geist>
yah shouldn't happen. but you can still do TLB and cache management instructions with them disabled
<clever>
the other problem ive run into, is more of a question of how usb is meant to work
<geist>
also i guess why full tlb and cache dumps aren't 1 cycle (though i haven't timed it)
<geist>
it must run through some sort of logic to whack all the tags back to 0
<clever>
a single usb transfer, is made up of multiple packets, up to max-packet-size
<clever>
and the only sign that a transfer is done, is that youve send something shorter then MPS
<geist>
right
<clever>
but, when doing the first get dev descriptor, you dont know the MPS, and assume its just 8
<geist>
i think control transfers are different
<clever>
if i follow the rules, that means i should expect an 8byte packet, and a 0 byte packet
<clever>
but, if i program the dwc to expect that, it hangs
<geist>
that whole zero byte thing is a) just a convention and b) i think only really apply to bulk/ionterrupt stuff
<clever>
ahh
<clever>
so you think control is special, and doesnt do that
<clever>
that could work
<geist>
i think therre are cases where if you know the precise length of the bulk packet the device/implementation may not require that
<clever>
up until now, i was doing everything over HS, and everything fit within 1 MPS
<geist>
like, iirc, mass storage when you transfer say a 512 byte sector you can stop at the end of it, because it's implied that it's a 512 byte sector
<geist>
therefore theres no need for there to be effectively a 'stop bit'
<clever>
but, for testing, i switched to the zero (to get rid of the hub), and plugged in my keyboard dongle
<clever>
the config descriptor is 59 bytes, and MPS is 8
zxrom has quit [Quit: Leaving]
<clever>
so, i must expect 7*8 and then a 3
<geist>
yah i think that's why by convention the first thing you do is read 8 bytes of the config header because it tells you a) the size of MPS and b) the total length of the header
<clever>
and based on what youve said, i can ignore the extra 0-byte packet at the end, for EP0
<geist>
and then you can do a transfer of the full thing using as many packets as yo uneed
<clever>
yep
<clever>
but the bug, was that when i assume MPS=8, the logic says an 8byte read, should return 8 then 0
<clever>
but maybe just ignore that for EP0 ....
<geist>
yeah. i'm not sure where the 0 byte transfer thing is documented, or if it's just a convention that some class devices and implementations do when the transfer size isn't known up front
andydude has joined #osdev
<geist>
a good eample would be retrieving a unknown sized ethernet frame off a usb eth thing
<geist>
you could queue up to a 1500 byte transfer but you dontk now how big it's going to be
<clever>
oh, and another problem i have, i cant get MSD working
<geist>
and it'd be a waste if it always padded it out to max transfer
<clever>
tinyusb sends a `SCSI Test Unit Ready` command
<clever>
which involves a 31 byte bulk-out, then a 13 byte bulk-in
<clever>
the bulk-in just perpetually hangs with NAK
<geist>
yah iirc, the MSD stuff always has a 13 byte header/footer, iirc
<geist>
iirc it's the response packet
<clever>
yeah, thats what i was expecting, from usbmon and the headers
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<clever>
but the NAK is what stumps me
<geist>
sounds like it probably didn't really grok the 31 byte thing
<geist>
so it's got nothing to send you in response
<clever>
another person i talked to, says a device will STALL if you give it an invalid command
<geist>
or it's not ready
<clever>
and NAK if its busy processing it
<geist>
ah that's probably true
<geist>
so it never stops NAKing it?
<clever>
correct
<geist>
hmm, dunno
<geist>
is this a real device or emulated?
<geist>
maybe you crashed the device
<clever>
a sony usb stick
<clever>
Bus 001 Device 073: ID 054c:0243 Sony Corp. MicroVault Flash Drive
<geist>
maybe it doesn't understand that command and crashed its rtos
<geist>
wouldn't be the first time i've seen that. 'does it work with windows? ship it'
<clever>
i have also noticed differences in how MSD's work
<geist>
probably not, but it's a possibility
<clever>
one of them, will NAK the 0-byte OUT, from the ACK phase of a control-in, when fetching descriptors
<clever>
and my code only supports NAK's on IN packets
<clever>
so my buggy code, retries it as IN, and everything goes downhill from there
<clever>
ive also used usbmon to spy on linux, with that same sony usb stick
<clever>
and it sends nearly the identical `Test Unit Ready` command (just the tag differs)
<clever>
and the drive responds instantly
<clever>
(but usbmon cant show NAK)
<geist>
right, was gonna say it might not show things like NAKs or zero lengh transfers
<geist>
kinda like ow say tcpdump doesn't know when ethernet does TSO or whatnot
<clever>
and when i was implementing DWC device before, usbmon didnt show anything, until i finished the transfer with a 0-length packet
<clever>
the host was stuck waiting for the end, and never told linux about the partial
<geist>
wish i could loan you my usb bus analyzer
<gog>
hi
<geist>
it makes these sort of problems trivial
<clever>
yeah
<geist>
gog!
<geist>
a wild gog appears
<clever>
i saw somebody from adafruit using a beagle480 before, and it would help greatly
* gog
attack
<clever>
but another option, you could just boot my binary, pop in a usb, and see what happens
<geist>
yah, tat's what i have, have a beagle480
<clever>
another thing i have yet to fully grasp, is split transactions
<clever>
with a HS hub in the way, i'm limited to HS only devices
<clever>
with the zero, i can plug a LS device directly in, and it works up until the packet-count thing mentioned before
<geist>
yah that part i dunno at all
<geist>
last time i did any serious usb hackery was maybe 12 years ago and eventhen was still mostly device side, HS
<geist>
and thus didn't have to worry about usb 3
<geist>
or split transactions or anything
<geist>
since that was the upstraeam hub's problem
<clever>
yeah
<clever>
even if your a LS device, the hub hides all that
<geist>
yah
<geist>
but i might do some more hackery now that i finished Death Stranding
<geist>
been basically marathoning that the last 2-3 weeks, and it's soaked up all my free time
<geist>
but finished it last night, so i can think about someting other than that
<clever>
i still have ~3 ways to debug MSD
<clever>
1: MSD gadget on a pi-zero, and pray usbmon can sniff the gadget
<clever>
2: MSD gadget on an rp2040, it can lock every transfer, but its FS
<clever>
so 2a, implement split transactions
<clever>
2b, shove the pico onto a zero
<clever>
2c, disable HS in the dwc, and hope the hub works at FS?
<geist>
4: get a better device that doesn't use DWC2
<geist>
basically i wont touch DWC2 unless it's for some work thing, and then i will protest
heat_ has quit [Remote host closed the connection]
<geist>
thankfully usb 3 has basically flushed it out of the system and no new SOCs will use it. they put DWC3 on now, but that's at least XHCI based
<clever>
4 conflicts with the end-goal, to get usb-boot on the open firmware
<geist>
and i think somewhat reasonable well
heat_ has joined #osdev
<geist>
a
<geist>
ah yes the open firmware thing for rpi is your goal
<geist>
well, time for me to go hack my VAX because that makes so much more sense! :)
<clever>
:D
<geist>
actually i should fiddle weith it some, last i tried to boot it it was having trouble reading the SCSI2SD that it worked with just before
<clever>
i'm thinking, fix the dma and packet-counts, and then it should work better
<geist>
maybe a firmware update on the scsi2sd, etc
<geist>
also suggestion: try a lot of usb sticks. it may be the sony one is particularly garbage
<geist>
sony is not well known for usb sticks in general
<clever>
ive tried 3 different sticks
<clever>
2 hang at the same place
<clever>
the 3rd NAK's during the ack phase of control-in, and my code doesnt handle that properly
<geist>
not that you dont need to make it work, but may make sense to find the one that is the most tolerant, get it fully working, and then go back and figure out the diff
<geist>
ah okay
<geist>
also may be transferring garabge, make sure your cache flushes are proper
<clever>
dma isnt active currently
<clever>
due to the write-once register, i wasnt able to turn it on
<clever>
so everything is PIO, manual fifo read/write
<clever>
but now that ive figured out the reset issues, i think i can turn DMA on
<clever>
and my FIFO code is fugly, and will break with a 2nd packet
<clever>
so DMA is going to be a better fix for that
<geist>
cool
<geist>
well, off to do weekly housework
<clever>
HS ping is also better in dma mode
vinc has joined #osdev
<clever>
in PIO mode, ping is 100% manual, so you have to react to an irq, then fill the tx-fifo
<clever>
in DMA mode, ping is fully automated, it will use DMA to fill its own fifo, when the time is right
Jari-- has joined #osdev
particleflux_ has quit [Ping timeout: 245 seconds]
andydude has quit [Quit: Leaving.]
rorx has joined #osdev
<gog>
i'm upgrading pray for mer
<heat_>
geist, can you check if your ia64 linux toolchain can compile ski-bootloader from that fork i posted yesterday?
<heat_>
the ia64-elf one seems... broken
<heat_>
boot_head.S:21: Error: MRI mode not supported for this target
<heat_>
even can't compile normal C code
gog has quit [Quit: byee]
<geist>
i built ia64-elf too
<geist>
well, cant right now but i can give it a shot a bit later
<heat_>
i get MRI errors when compiling ski-bootloader, and a bunch of "Warning: Explicit stops are ignored in auto mode" for other stuff
<heat_>
(including libgcc)
gog has joined #osdev
<gog>
upgrade worked'
<heat_>
upgraded what?
<gog>
distro
<heat_>
oh sorry i didn't pray
<heat_>
you really did need prayers since you're running manjaro
<gog>
yes
<gog>
thankfully i haven't offended the goddess recently
<mcrod>
this might come as a shock to some of you
<mcrod>
but writing C89 seems very.. cool
<gog>
no thanks
<gog>
i like c23
<mcrod>
the problem is
<mcrod>
in an embedded world, C89/C99 is still king
<mcrod>
that is until someone ports architecture 'x' to clang
<mcrod>
or gcc, whatever
<gog>
true
<gog>
and unlikely
<mcrod>
I really don't believe for a moment that STM8 (been saying that arch for almost 2 weeks now, but in this case, example) would be non-trivial to port to clang
<mcrod>
but it would never get merged with mainline clang
<gog>
yeh so you'd be maintaining a fork of clang forever
<gog>
if you were to do so
<gog>
i would not want to do that
<mcrod>
right
<heat_>
why would it not get merged?
<mcrod>
who the hell cares about STM8?
<heat_>
embedded people
<heat_>
who the fuck gives a shit about hexagon?
<mcrod>
so? embedded people are usually smart enough and pick ARM based MCUs
<mcrod>
and then all is right in the world
<mcrod>
except here
<mcrod>
i think the AVR target on clang is still experimental
<heat_>
<heat_> who the fuck gives a shit about hexagon?
<mcrod>
that's a DSP, and that makes sense to care about
<heat_>
because?
<heat_>
what im getting at here is that the bar for inclusion upstream isn't usually all that high
<heat_>
both for llvm and gcc
<heat_>
hell, even linux
<mcrod>
the problem is will someone want to maintain it going forward
<mcrod>
i won't be around forever
<heat_>
sure, you/your corp, that submitted it
particleflux has joined #osdev
<heat_>
if you can't maintain then it's usually time to axe
<mcrod>
there are things that prevent LLVM from being the one stop shop in the embedded world
<heat_>
or in linux's case, maintain forever due to nostalgia/weirdos that really like old and obscure systems
<mcrod>
e.g., clang-tidy doesn't support MISRA C at all, the lack of being able to make a phone call and get immediate help (which, no one does for IAR, but it appeals to corporate drones)
<geist>
hexagon is really big
<geist>
and it's big in a way where you dont get to choose: it's qualcomms thing
<clever>
hexagons are bestagons!
<geist>
so if you're using one of their cores, hexagons all the way down
<geist>
they are the bestagons
<geist>
bees like it!
<mcrod>
at work we have PC-lint, which is ironically LLVM based
<mcrod>
does fairly good MISRA C linting
<mcrod>
read: i'm not saying LLVM isn't suitable for embedded development, that's mostly bullshit
<mcrod>
i'm saying that it is *incredibly difficult* to get embedded developers who've used IAR since I was learning my ABCs, to go to a completely free solution no matter how good it is
<heat_>
right
<heat_>
but you *can* change that
<mcrod>
it'd be nice if I could compile our entire project, all boards and all with LLVM
<heat_>
i.e you're the next gen
<clever>
geist: got dma working, just had to deal with irq's firing in a diff order, and my code not handling it right, on to packet stuff!
<mcrod>
yeah I mean, my boss is certainly open to dropping IAR one day since the IDE crashes every 10 seconds.
<mcrod>
but IDE != compiler, and we would be able to use the compiler just fine, at a cost of $6,000/seat
<mcrod>
sorry, I rant about IAR more than I should, because it's absolutely silly
<mcrod>
the sole exception being if you need a safety certified toolchain
<gog>
i'm safety-certified
<geist>
one you get your claws trimmed
<geist>
once
<gog>
never
<mcrod>
gog may I decompile you
<gog>
yes
<heat_>
kinky
heat_ is now known as heat
* mcrod
decompiles gog
<geist>
decompiles to sugar and spice?
* gog
.asciiz "prr"
<heat>
gnu as good, att syntax good
<heat>
downvotes to the left u intel hippies
<gog>
i'm bisyntactic
<heat>
gog gog
<heat>
whats your favourite kernal
<gog>
haiku
<heat>
good choice
<heat>
more geist more better
<gog>
yes
<geist>
yay
<gog>
haiku underrated
<Cindy>
what do you do when you find a program with another text encoding
<Cindy>
like not ".asciiz"
<heat>
cry?
<geist>
well, guess it depends on what the encoding is
<Cindy>
is there like an assembly statement for a text with a different encoding?
<Cindy>
it's russian text in windows-1251
<geist>
like, say, anything UEFI where you have 16 bit unicode
<bslsk05>
openbios/fcode-utils - A set of utilities to process FCODE, OpenFirmware's byte code (13 forks/26 stargazers/GPL-2.0)
<geist>
but quickly got kinda silly and i pivoted to a devfs
<heat>
damn geist you really took the UNIX philosophy to heart
<Cindy>
like /ap for audio processor, or /vid for the video device/processor
<heat>
were files all plain text?
<Cindy>
and /cd/* for the cd drive
<geist>
no, but it was something like pci would make a fs with all the nodes, and then pci devices would mount over the top of the node whent hey claimed it, etc
andydude has joined #osdev
<geist>
was like /dev/bus/...
<heat>
no plain text no UNIX likey
<clever>
and dma strikes once more, 32bit write to an 8bit var, in the middle of a struct!
* clever
waves goodbye to state
<Cindy>
(i put /* as in to point out that it has a virtual filesystem inside that you can access, filesystem modules don't have to have a virtual filesystem inside a device)
<geist>
but then each device was basically a root dir with a few nodes
<geist>
for info, etc
<heat>
geist, how would that work if you wanted to access PCI functionality for a device and a driver mounted over it?
<geist>
oh i dunno, i didn't get that far
Gooberpatrol66 has joined #osdev
<geist>
it was just the idea and then i got tired of it and switched to a more standard devfs
<Cindy>
OS-9 filesystem was designed that the root is basically just devices
<Cindy>
you can't store files in root
<geist>
yeah, i was taking hints from beos, which has the same thing
<geist>
there's an implicit rootfs that holds / and can only hold dirs for mountpoints for other stuff
<geist>
so the beos fs was like / /boot /home /other_mount_points
<geist>
oh yeah rootfs could also do symlinks so you could set up /bin -> and /usr -> and whatnot for posix compat
<geist>
seems reasonable to me
<Cindy>
the OS-9 filesystem was like that
<Cindy>
if you wanted to access the root of your hard drive
<Cindy>
you would do /h0
<Cindy>
like /h0/someshit.txt
<heat>
geist, oh i think macOS's / is immutable now?
<heat>
well, "now"
<heat>
more like a few years ago
<geist>
yeah wouldn't be surprised
<geist>
that sort of root is special, mount mutable things on top of it makes sense to me
<gog>
that's a design i have in mind actually
<gog>
root doesn't really exist
jjuran has joined #osdev
<heat>
ROOT DOESN'T EXIST WAKE UP SHEEPLE
<gog>
yes
<geist>
and due to the whole object heirarchy you can argue that NT always did this, etc
<geist>
//./ etc
<Cindy>
difference between beos and OS-9
<geist>
er \\.\
<Cindy>
is that in beos, you can have mountpoints in the root
<Cindy>
OS-9, it's only devices and that's it
<heat>
backslash >> forward slash
<heat>
praise be windoze
<Cindy>
no
<Cindy>
how dare you
<Cindy>
i have had enough of escaping backslashes in C
<heat>
tbf i don't have much to say about windows nt in a technical perspective because i don't understand much of it
<geist>
i kinda like : as a path separator to be honest
<geist>
the \ came from all the earlier things that it copied all the way back to some DEC
<geist>
DEC oses
<moon-child>
I AM ROOT
<heat>
all i know about nt is that the MM isn't all that different from linux
<heat>
i.e the PTE thing
<geist>
well, actually i say that, CP/M i dont think had dirs like that, so may be that DOS did indeed locally invent their own path separators
<geist>
which considering they were also supporting xenix at the time it is kinda strange that / wasn't picked
<heat>
brb rebooting into backslash
heat has quit [Remote host closed the connection]
<nortti>
iirc in dos 2.0 you can configure the command line flag (defaults to '/') and path separator (defaults to '\')
<gog>
i prefer / as a path sep since it's stndardized in urls
<gog>
but : has charm
<gog>
or even ::
heat has joined #osdev
<heat>
\\\\\\\\\\\\
<nortti>
also another option is that special device files are only present in a pseudodir called "dev" on root of every drive
<heat>
i like .
<nortti>
meaning that you could run a dos system where you do "dir -w > /dev/prn"
<nortti>
however there was already a bit of software that used '/' to mark the start of a command line flag for dos 1.x, and there wasn't really much reason to configure those switches to something non-default, so the support from dropped from latter versions of DOS
<heat>
that's pretty UNIX
<nortti>
aye dos 2.0 was an attempt by microsoft to bring dos closer to xenix
<mjg>
gotta love how we all roll with arbitrary bullshit today
<mjg>
can you name a file 'con' in windows today?
<gog>
i want to make up my own arbitrary bullshit'
<gog>
no that's still illegal
<nortti>
I thought they allowed some more things in windows 11?
<mcrod>
i can't wait until it is 18-20C in my room
<gog>
iirc it's still a reserved name
<heat>
that's ILLEGAL
<heat>
you're going away for a long time you perv!
<kazinsal>
go full classic macos, use : as your path separator
<geist>
i think it's just the win32 api of course, the lower level stuff i think allows it just fine
<gog>
you'll never take me alive, filename cops!
<moon-child>
I'm gonna use a space as my path separator
<geist>
and it always has to handle the situation where a FS has a file of that name
<mcrod>
sometimes i think the only reason i come here is to listen to these wonderful conversations we have
<mjg>
1etc2motd
<nortti>
< nortti> aye dos 2.0 was an attempt by microsoft to bring dos closer to xenix ← https://www.youtube.com/watch?v=Vo8NG8T4rWs pardon the clickbait title, but this video explains the (pretty interesting) history much better than I could
<bslsk05>
'XEDOS - Microsoft's forgotten Linux-like OS from 1981 revealed! #DOScember' by VWestlife (00:13:04)
<mjg>
<1>usr<2>local<3>bin<4>zsh
<CompanionCube>
RISC OS seems to have the weirdest seperators
<mjg>
i think the above is most useless
<mjg>
totally gonna implelment that for ONYX
<heat>
moon-child 𓂺
<heat>
this is better
<CompanionCube>
'^.^.greatgrandparent' actually this one is cool