elastic_dog has quit [Killed (mercury.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
billchenchina- has joined #riscv
jacklsw has joined #riscv
aredridel8 has joined #riscv
prabhakarlad has quit [Quit: Client closed]
aredridel has quit [Ping timeout: 256 seconds]
aredridel8 is now known as aredridel
BootLayer has joined #riscv
jay321 has joined #riscv
jay321 has quit [Ping timeout: 248 seconds]
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #riscv
Tenkawa has quit [Quit: Was I really ever here?]
jay321 has joined #riscv
billchenchina- has quit [Ping timeout: 248 seconds]
jay321 has quit [Ping timeout: 248 seconds]
<muurkha>
zBeeble: what said your filesystem needed to change was Bard, not GPT-4, which correctly explained that SV49 was mostly a hardware and kernel issue; see the link I posted, not the bullshit posted earlier
<muurkha>
ChatGPT was possibly not involved
<muurkha>
the incorrect Bard answer, in particularm was not from ChatGPT
<muurkha>
it's true that pointer tagging, like virtual memory, is pretty architecture-dependent. it's also true that it's a huge performance boost for dynamically-typed languages and ML
heat has quit [Read error: Connection reset by peer]
<muurkha>
typically the standard ABI guarantees pointer alignment, which (as dh` pointed out) lets you use low bits for pointer tags, which is by far the most common way to do it
heat has joined #riscv
<muurkha>
(also of course if your runtime allocates the pointers it can control their alignment)
<muurkha>
as dh` also said
<muurkha>
dh`: you could use the high 8 bits for tags on 68k at first IIRC? and maybe armv1?
<muurkha>
also I think on S/360
heat has quit [Ping timeout: 240 seconds]
heat has joined #riscv
bauruine has joined #riscv
frkazoid333 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #riscv
aredridel2 has joined #riscv
PobodysNerfect has joined #riscv
aredridel has quit [Ping timeout: 250 seconds]
aredridel2 is now known as aredridel
terminalpusher has joined #riscv
<courmisch>
dh`: if you store everything as (u)intptr_t, it's supposed to work indeed, but IME people "recklessly" cast back to a pointer type. Fortunately, with void * or char *, it should just work.
<courmisch>
dh`: but I've seen GCC do really weird thing when giving it unaligned pointer values (as in less aligned than the pointed-to-type requiers)
<courmisch>
(and GCC had every right to screw that up since it's undefined)
<courmisch>
but well, I agree that if done correctly, it can work
jacklsw has quit [Quit: Back to the real world]
heat has quit [Remote host closed the connection]
heat has joined #riscv
<dh`>
muurkha: sufficiently old m68k yeah, but like with current 64-bit stuff it would have broken rapidly
<dh`>
armv1 idk
<dh`>
courmisch: yeah there are lots of things you definitely can't do :-)
<muurkha>
well, 'rapidly' is a matter of perspective
<dh`>
iirc it broke by the time the 68020 appeared and that was less than five years from the point anyone would have bothered doing such stuff on m68k
<dh`>
world changed much faster back then
<muurkha>
I think it was actually the '30
<dh`>
idk
<muurkha>
but sure, five years
<dh`>
may have varied, also, there were a lot of custom m68k mmus
<muurkha>
but last time I worked at a startup, five years was an incomprehensibly long time
<muurkha>
three months was a long time
<muurkha>
there were a *lot* of companies with ads in computer magazines in 01979 that didn't exist in 01984
<muurkha>
and of course '020 sales didn't drop to zero instantly
<muurkha>
sun3x in 01989 was Sun's first '030 machine
<muurkha>
so of the things that might kill your Smalltalk or Lisp company that started in 01982 or 01983, Motorola shipping a chip with a more than 24-bit address bus was pretty far down the list
<dh`>
wikipedia thinks it's the 020
<dh`>
(don't have the energy to look anywhere more authoritative right now)
<muurkha>
oh, you're right, I was confused
<dh`>
timeline for apple seems to have been late 1984 (original mac) to early 1987 (mac II)
<dh`>
which is a bit over two years
<muurkha>
yeah, apple lisps got boned
<dh`>
which, yes, is enough time for a lisp startup to get itself in trouble
<muurkha>
and hopefully get enough of a revenue stream to hire more hackers to get it out
<dh`>
but barely enough time to turn around in from a system design point of view
<muurkha>
yeah
<muurkha>
otoh the mac II was predictable by 01985
<dh`>
significantly less time than march 2020 to now
<muurkha>
heh
<dh`>
apple enjoyed being unpredictable even back then
<muurkha>
yeah, I sure have a lot of system designs I haven't turned around since then
<muurkha>
well, I mean, they could have canceled the Mac
<muurkha>
but they obviously weren't going to stick with obsolete CPUs forever
jacklsw has joined #riscv
<dh`>
I guess it's other aspects of the mac II that were less predictable (color, different size screen, etc.)
<muurkha>
oh, sure
<muurkha>
1-bit GUIs are a visually interesting design space
<dh`>
I guess, it's one I'd just as soon never visit again
<muurkha>
well, I've written sonnets and a 64-byte demo, so I have a taste for restrictions breeding creativity
<muurkha>
also though I have some 0.1-megapixel 1-bit displays that run on 50 μW
<dh`>
sure, just some restrictions aren't fertile and this has always seemed like one
<muurkha>
great contrast, super permissive timing requirements, 60fps, reasonably low latency
<muurkha>
but 1 bit deep
<muurkha>
two wire serial interface
<muurkha>
I think I can get 10 DMIPS and 0.2 megapixels on a milliwatt
<dh`>
0.2 megapixels isn't a useful measurement
<dh`>
400x500?
<geertu>
640x312?
<dh`>
512x342?
luffy[m] has quit [Quit: Bridge terminating on SIGTERM]
khem has quit [Quit: Bridge terminating on SIGTERM]
patersonc[m] has quit [Quit: Bridge terminating on SIGTERM]
psydroid has quit [Quit: Bridge terminating on SIGTERM]
pierce has quit [Quit: Bridge terminating on SIGTERM]
jim-wilson[m] has quit [Quit: Bridge terminating on SIGTERM]
thefossguy has quit [Quit: Bridge terminating on SIGTERM]
acharles has quit [Quit: Bridge terminating on SIGTERM]
mtinman[m] has quit [Quit: Bridge terminating on SIGTERM]
Gravis_ has joined #riscv
Gravis has quit [Ping timeout: 268 seconds]
juliadev has quit [Quit: routing issues]
MaxGanzII_ has joined #riscv
paddymahoney has joined #riscv
ldevulder has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
MaxGanzII_ has quit [Ping timeout: 240 seconds]
meta-coder has joined #riscv
Leopold has joined #riscv
khem has joined #riscv
dionysos is now known as undercaffeinated
Wickram has joined #riscv
pierce has joined #riscv
thefossguy has joined #riscv
acharles has joined #riscv
patersonc[m] has joined #riscv
luffy[m] has joined #riscv
psydroid has joined #riscv
MaxGanzII_ has joined #riscv
jacklsw has quit [Ping timeout: 240 seconds]
enthusi has quit [Remote host closed the connection]
<drewfustini>
I've not seen something like that before... anyone have ideas how to debug?
<drewfustini>
Maybe just bisect?
awita has quit [Ping timeout: 240 seconds]
<dh`>
uh, first step is to check where it's faulting...
<drewfustini>
I'll turn on DWARF so I can get better stack trace
<drewfustini>
hopefully that will make it easier to understand what is at badaddr: ffffaf8000000000
<muurkha>
that looks like Linux
ldevulder has quit [Quit: Leaving]
<somlo>
just a rando data point, I had something like that happen when opensbi, the DTB, and the kernel were getting overlapped in RAM during early boot
<somlo>
the booting kernel was executing garbage opcodes because opensbi placed the dtb on top of some of its opcodes...
q66__ has joined #riscv
<conchuod>
drewfustini: is the system sv48 by any chance?