<meowray>
say, i want to pick a uint32_t to be placed before a function entry. this integer ideally is an invalid instruction encoding on all architectures. what values may be good? a lot of values appear to be powerpc instructions...
<meowray>
linux kernel seems to prefer 0xdeaddead?
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
terminalpusher has quit [Remote host closed the connection]
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
vagrantc has quit [Quit: leaving]
tusko has joined #riscv
<tusko>
forgive my limited knowledge on this subject but is one of the selling points of riscv the ability to create custom processors, with instructions vastly different from what is found in general purpose cpus/gpus?
tjaden has joined #riscv
jacklsw has joined #riscv
eroux has quit [Ping timeout: 250 seconds]
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
Noisytoot has quit [Ping timeout: 240 seconds]
Noisytoot has joined #riscv
billchenchina has joined #riscv
billchenchina has quit [Remote host closed the connection]
billchenchina has joined #riscv
<muurkha>
tusko: RISC-V does provide that, and there are surely designers who value it; is that what you mean?
bauruine has joined #riscv
<tusko>
like I hear about 'AI processors' what is it about AI that requires special processors? How are those processors likely to differ from general purpose CPUs?
<tusko>
I usually think of things like compute-in-memory when I think of these applications, but today I don't know anymore
<tusko>
that does look interesting, thank you for that
<jrtc27>
masses of vector / matrix operations without a need for much precision or range
<jrtc27>
sometimes as tiny as 8-bit floats
sh1r4s3 has quit [Remote host closed the connection]
davidlt has joined #riscv
sh1r4s3 has joined #riscv
<tusko>
That's actually an interesting idea
<tusko>
I suppose if high precision isn't needed its clever
guerby_ has joined #riscv
guerby has quit [Read error: Connection reset by peer]
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
<jrtc27>
that's what most of these ai accelerators are really providing
<jrtc27>
lots of fast low-precision arithmetic
sakman has joined #riscv
jack_lsw has joined #riscv
<muurkha>
most of our own neurons' computations are done with spikes
<muurkha>
a spike is sort of like a single-bit channel with a duty cycle of around 0.1%
jacklsw has quit [Ping timeout: 255 seconds]
<muurkha>
the channel is thus transmitting, at best, about 10 bits of information one out of every 1000 time slots (plus 1.4 bits in the other 999 timeslots), so you could say it's about 0.001 bits per time slot
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
billchenchina has quit [Ping timeout: 260 seconds]
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
davidlt has quit [Ping timeout: 255 seconds]
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs3 has joined #riscv
Forty-Bot has quit [Ping timeout: 265 seconds]
Forty-Bot has joined #riscv
vigneshr has quit []
vigneshr has joined #riscv
sh1r4s3 has quit [Remote host closed the connection]
sh1r4s3 has joined #riscv
sh1r4s3 has quit [Remote host closed the connection]
<palmer>
alex found whatever that LLVM issue was, he's going to post to LKML
MaxGanzII has quit [Ping timeout: 255 seconds]
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
pharonix71 has quit [Remote host closed the connection]
pharonix71 has joined #riscv
awita has joined #riscv
hrberg has joined #riscv
jacklsw has quit [Ping timeout: 260 seconds]
jacklsw has joined #riscv
jobol has quit [Quit: Leaving]
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
awita has quit [Remote host closed the connection]
jacklsw has quit [Quit: Back to the real life]
vagrantc has joined #riscv
monoidog has joined #riscv
Wickram has quit [Ping timeout: 255 seconds]
Stat_headcrabed has joined #riscv
<jrtc27>
hm, so how does not having -fpie break things?
<jrtc27>
shouldn't that just result in linker errors?
<jrtc27>
or does the kernel just silently blow up if it's a PDE?
MaxGanzII has joined #riscv
<nathanchance>
palmer: There appears to be a new section mismatch warning after https://git.kernel.org/riscv/c/62a31d6e38bd0faef7c956b358d651f7bdc4ae0c: WARNING: modpost: vmlinux.o: section mismatch in reference: smp_callin (section: .text) -> probe_vendor_features (section: .init.text)
Stat_headcrabed1 has joined #riscv
Stat_headcrabed has quit [Ping timeout: 260 seconds]
Stat_headcrabed1 is now known as Stat_headcrabed
<palmer>
thanks, not sure why I didn't see it
<Stat_headcrabed>
conchuod: Yes, I would Cc you next time. Besides, I think cover detachment might be a bug of git, try other distro for a newer version next time..
<conchuod>
Whoops, warning: symbol '__pcpu_scope_misaligned_access_speed' was not declared. Should it be static?
<conchuod>
nathanchance: Hmm, wonder why my stuff didn't see a failure for the nommu config
<palmer>
probably, do you want to just send a fix? turns out my local cross toolchain got hosed by yesterday's update, so I've got to re-spin it
<conchuod>
Yah, I shall
* jrtc27
sighs
<jrtc27>
so that hwprobe crap is now in for-next
<jrtc27>
great...
<jrtc27>
platform fragmentation here we come
handsome_feng has quit [Quit: Connection closed for inactivity]
<Stat_headcrabed>
Bad news
<Stat_headcrabed>
another c906 chip coming
<Stat_headcrabed>
sophon cv1800b
<conchuod>
Is that the 64 core "server"?
<Stat_headcrabed>
no
<Stat_headcrabed>
A MCU-size chip
<Stat_headcrabed>
64core is SG2042
heat has quit [Remote host closed the connection]
<Stat_headcrabed>
also sophon
<q66>
can i get a 64-core server
<conchuod>
You can only get a "server" q66, sorry.
<q66>
building a distro in qemu-user is not very fun
<Stat_headcrabed>
So is it possible for vector 0.71 upstream compiler support?
<q66>
64 cores would help even if potatoes
<conchuod>
Isn't Vrull working on upstream foo support for that stuff?
<conchuod>
mmind00: ?
heat has joined #riscv
<q66>
still hoping that maybe the p550 will be at least a bit faster than the qemu-user setup i have
<palmer>
Stat_headcrabed: if someone sends the patches I'm not opposed to it, but I think some other folks might be
<q66>
my emulated setup is 8x faster than hifive unmatched but also burns through hundreds of watts for no reason
<Stat_headcrabed>
I heard that gcc upstream already refused 0.71 support once?
<palmer>
we've at least got some GCC support for v-1.0 now, though, so we should be able to at least tack on the subset that's broadly similar to v-0.7
<palmer>
we refused it when we refused anything that was non-standard, there's vendor stuff in GCC now
<Stat_headcrabed>
Looking forward to K230/JH8100
<Stat_headcrabed>
which has vector 1.0 support
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<conchuod>
Stat_headcrabed: I see another thread with the same issue, so prob yeah. Are you using 2.25.1?
<conchuod>
(or similar)
heat_ has joined #riscv
Stat_headcrabed has joined #riscv
heat has quit [Ping timeout: 265 seconds]
Stat_headcrabed has quit [Client Quit]
___nick___ has joined #riscv
Tenkawa has joined #riscv
<palmer>
looks like we've also got `riscv64-unknown-linux-gnu-ld: warning: orphan section `.got' from `init/main.o' being placed in section `.got'
<palmer>
riscv64-unknown-linux-gnu-ld: warning: orphan section `.got.plt' from `init/main.o' being placed in section `.got.plt'`
<palmer>
nathanchance: I don't see the section mismatch errors locally, not sur eexactly what's up
prabhakarlad has quit [Quit: Client closed]
<courmisch>
JH8100 sounds like it won't quite be in the price range of JH7110
<nathanchance>
palmer: I can reproduce on -next building just ‘defconfig all’ with GCC 12.2.0 from https://kernel.org/pub/tools/crosstool/, I’ll try riscv/linux next, could be an issue that only shows up with another merge
<palmer>
thanks
frkazoid333 has quit [Ping timeout: 260 seconds]
<courmisch>
AFAICT, only interoperable subset between 1.0 and 0.7.1 is if SEW=8, TA=0, MA=0 and LMUL is not fractional
<courmisch>
since most code uses TA=1, that's pretty much the empty set
<courmisch>
it's a different question if you compile *only* for 0.7.1 of course
<palmer>
I don't think we'd have any binary compatibility, just that the MD patterns would be mostly the same
<palmer>
that's kind of the hard part, actually emitting the instructions/bits is pretty mechanical
<courmisch>
I couldn't be bothered to review the 700+ changes from 0.7.1 to 1.0, but there were just a few instructions added or changed, yes
<courmisch>
by far the main problem is the changed VCFG
<courmisch>
is it so that Star5 is moving away from SiFive and making their own CPU IP?
<nathanchance>
palmer: I cannot reproduce it on for-next and I do not have time to try and do multiple bisects to see what other commit is necessary to see it at the moment. I noticed the declaration of probe_vendor_features() has __init, whereas the definition has __init_or_module, which could make a difference for this warning when CONFIG_MODULES is set or just drop __init from probe_vendor_features() altogether.
<palmer>
Evan is going to fix it
heat_ has quit [Remote host closed the connection]
heat_ has joined #riscv
<FL4SHK>
so I have to say, RISC-V's Binutils port has proven to be pretty helpful in my own Binutils port
<FL4SHK>
so thanks to whoever wrote the RISC-V Binutils port
<FL4SHK>
I got linker relaxing for my target arch to work
<FL4SHK>
I have a partial GCC port as well, but the last time I worked on it was 2018, and the ISA has changed a little since then
<FL4SHK>
I also last worked on that GCC port before the Binutils port
<FL4SHK>
so I was examining GCC's assembly output, but couldn't run any of the testsuite
<FL4SHK>
by the way, the target arch is my own design, so I'm free to make changes to it :)
somlo_ has quit [Read error: Connection reset by peer]
BootLayer has quit [Quit: Leaving]
heat_ has quit [Remote host closed the connection]
heat_ has joined #riscv
frkazoid333 has joined #riscv
eroux has quit [Read error: Connection reset by peer]
<palmer>
nathanchance: Evan sent a patch
eroux has joined #riscv
jamtorus is now known as jellydonut
___nick___ has quit [Ping timeout: 260 seconds]
eroux has quit [Read error: Connection reset by peer]
eroux has joined #riscv
<nathanchance>
Sweet, thanks!
heat_ has quit [Remote host closed the connection]
heat_ has joined #riscv
unlord has quit [Changing host]
unlord has joined #riscv
monoidog has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
heat_ is now known as heat
vagrantc has joined #riscv
KombuchaKip has joined #riscv
jgaz has quit [Remote host closed the connection]
epony has joined #riscv
aerkiaga has quit [Ping timeout: 240 seconds]
aerkiaga has joined #riscv
<drewfustini>
It seems like the largest number of harts that linux can boot is 512 based on arch/riscv/Kconfig. Anyone know if only active harts count towards the NR_CPUS?
<drewfustini>
I'm imaging aa system where there might be 1024 harts but only 256 harts might be capable of running linux.
<drewfustini>
There would be a non-contiguous sparse number of harts out of the total range of hart ids (0 - 1023) that would be running linux (the other harts would be running non-linux code).
<Armand>
So... you'd say it's not.. full of hart.. ?
<drewfustini>
:)
<drewfustini>
the concept would be one SoC with 1024 risc-v harts but only a small number would run linux. the rest would be running other work loads.
<heat>
yes, I believe NR_CPUS only counts booted CPUs (in the linux sense)