sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv | Matrix: #riscv:catircservices.org
shoragan has quit [Read error: Connection reset by peer]
esv_ has quit [Quit: Leaving]
shoragan has joined #riscv
esv has joined #riscv
shoragan has quit [Quit: quit]
shoragan has joined #riscv
geist-sdf has joined #riscv
naoki has joined #riscv
naoki has quit [Client Quit]
Leopold has joined #riscv
Tenkawa has joined #riscv
heat has joined #riscv
heat_ has quit [Read error: Connection reset by peer]
Tenkawa has quit [Quit: Was I really ever here?]
iooi has joined #riscv
Leopold has quit [Remote host closed the connection]
marcj has quit [Ping timeout: 264 seconds]
iooi has quit [Read error: Connection reset by peer]
iooi has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
iooi has quit [Quit: iooi]
KREYREN_ has quit [Ping timeout: 260 seconds]
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
BootLayer has joined #riscv
Noisytoot has quit [Quit: ZNC 1.8.2 - https://znc.in]
Noisytoot has joined #riscv
jacklsw has joined #riscv
Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #riscv
Noisytoot has quit [Client Quit]
Noisytoot has joined #riscv
sakman has quit [Quit: Leaving]
marcj has joined #riscv
Noisytoot has quit [Quit: ZNC 1.8.2 - https://znc.in]
sakman has joined #riscv
Noisytoot has joined #riscv
Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #riscv
BootLayer has quit [Quit: Leaving]
stolen has joined #riscv
Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #riscv
Noisytoot has quit [Client Quit]
Noisytoot has joined #riscv
coldfeet has joined #riscv
Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #riscv
Noisytoot has quit [Remote host closed the connection]
Noisytoot has joined #riscv
mlw has joined #riscv
heat_ has quit [Ping timeout: 256 seconds]
ntwk has quit [Ping timeout: 268 seconds]
iooi has joined #riscv
craigo has quit [Quit: Leaving]
mlw has quit [Ping timeout: 255 seconds]
iooi has quit [Quit: iooi]
iooi has joined #riscv
mlw has joined #riscv
coldfeet has quit [Quit: Lost terminal]
pabs3 has quit [Remote host closed the connection]
pabs3 has joined #riscv
stolen has quit [Quit: Connection closed for inactivity]
davidlt has joined #riscv
davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
jfsimon1981_b has quit [Remote host closed the connection]
jfsimon1981_b has joined #riscv
Stat_headcrabed has joined #riscv
jacklsw has quit [Ping timeout: 264 seconds]
KREYREN_ has joined #riscv
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Andre_Z has joined #riscv
Noisytoot has quit [Ping timeout: 252 seconds]
Noisytoot has joined #riscv
BootLayer has joined #riscv
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
BootLayer_ has joined #riscv
BootLayer has quit [Ping timeout: 264 seconds]
naoki has joined #riscv
naoki has quit [Client Quit]
<conchuod> bjoto: Have you tried either nam' or ted's suggestions?
<conchuod> Ted's didnt trigger when I tried it (at least as far as I could see) but Nam's boots..
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #riscv
bitoff has joined #riscv
bitoff has quit [Ping timeout: 260 seconds]
ntwk has joined #riscv
Stat_headcrabed has joined #riscv
KREYREN_ has quit [Ping timeout: 260 seconds]
KREYREN_ has joined #riscv
Tenkawa has joined #riscv
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #riscv
psydroid has joined #riscv
BootLayer_ has quit [Quit: Leaving]
heat_ has joined #riscv
bitoff has joined #riscv
bitoff_ has joined #riscv
bitoff has quit [Ping timeout: 255 seconds]
heat has joined #riscv
heat_ has quit [Read error: Connection reset by peer]
haasn has joined #riscv
<haasn> I can't explain why my assembler seems to completely ignore %lo(symbol) and resolve them all to zero:
<haasn> something as simple as li a0, %lo(foo) .zero 32 foo: ret disassembles to `li a0, 0 ..... ret`
<haasn> Needless to say, it also breaks on every `call`. `jal foo` translates to `jal 24 <foo>`, but `call foo` translates to `jal # 0 <foo-0x28>`
<haasn> I'm using GNU assembler version 2.42.0 (riscv64-suse-linux) using BFD version (GNU Binutils; openSUSE Tumbleweed) 2.42.0.20240130-2
<haasn> It seems that this assembler simply ignores the existence of all symbols and silently treats them as 0 in all contexts except local jumps `jal / b*`
<haasn> I refuse to believe that version 2.42.0 of a popular assembler could simply fail to assemble anything involving the `call` instruction correctly, so what is going on here?!
<haasn> https://riscvasm.lucasteske.dev/# seems to work fine on the exact same input file
<Tenkawa> Yeah that sounds like something else... that's what I'm running natively here
<Tenkawa> na@star64:~$ as -v
<Tenkawa> GNU assembler version 2.42 (riscv64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.42
<haasn> Maybe my system is shipping a completely broken assembler binary
<Tenkawa> Unfortunateky ny exposure to suse stopped back in the late 90's
<Tenkawa> er my
<Tenkawa> s/Unfortunateky/Unfortunately
KREYREN_ has quit [Remote host closed the connection]
davidlt has quit [Ping timeout: 260 seconds]
<haasn> Hmm no it also breaks on a Ubuntu 22.04 LTS box
<haasn> printf 'call foo\n foo: ret\n' | riscv64-linux-gnu-as - -o binary && riscv64-linux-gnu-objdump -d binary
<haasn> compiles to the same `jalr ra # 0 <foo-0x8>`
KREYREN_ has joined #riscv
<haasn> instead of the expected `jalr ra # 8 <foo>`
<haasn> (the website I linked actually somehow simplifies that into `jal ra, 4`)
<haasn> I'll report an upstream bug I guess.. let them figure out what's going on
KREYREN_ has quit [Remote host closed the connection]
junaid_ has joined #riscv
<haasn> this may be the strangest bug I've ever filed
<Tenkawa> I had some wild "internal" ones in my development days where I worked but that was long long ago
<Tenkawa> We did a lot of assembly and cobol
<haasn> Oh, I'm being stupid, aren't I?
<haasn> I assemble the object file, but I never *link* it
<haasn> Running it through `-ld` as well fixes everything.. sorry for the noise
<Tenkawa> Hey... I wasn't thinking either... (still half asleep...)
junaid_ has quit [Quit: leaving]
duckworld_ has joined #riscv
duckworld has quit [Ping timeout: 244 seconds]
duckworld_ is now known as duckworld
Stat_headcrabed has quit [Quit: Stat_headcrabed]
<haasn> Hrm, another problem: when I use `clang` to compile a C binary to RISC-V, it ends up placing symbols wherever it wants to. But my microprocessor always starts executing at 0x0, is there any way I can force it to place _start here?
<sorear> put _start in its own section and use a linker script to put that section first
<sorear> ("placing symbols" is done by the linker, typically GNU ld.bfd or lld; neither is strictly speaking part of clang, although clang runs them automatically)
<haasn> Not sure how to do that with clang, it seems it always puts _start into .text as well
<haasn> Well, I "solved" it for now by just also linking in a `boot.S` containing `call _start`
davidlt has joined #riscv
<heat> do what?
<heat> you want a linker script to control the addresses and positioning of individual sections within your binary, whether or not your symbols go to a given section depends on the type of the symbol (and if you're using __attribute__((section)))
schmendrick3312 has joined #riscv
schmendrick3312 has quit [Ping timeout: 250 seconds]
___nick___ has joined #riscv
BootLayer has joined #riscv
craigo has joined #riscv
ntwk has quit [Ping timeout: 256 seconds]
Narrat has joined #riscv
BootLayer has quit [Quit: Leaving]
neil has quit [Ping timeout: 256 seconds]
neil has joined #riscv
neil has quit [Quit: When life gives you lemons, make orange juice and then sit back as people wonder how you did it.]
neil has joined #riscv
psydroid has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
davidlt has quit [Ping timeout: 264 seconds]
neil has quit [Quit: When life gives you lemons, make orange juice and then sit back as people wonder how you did it.]
indyZ has joined #riscv
neil has joined #riscv
paulk has quit [Quit: WeeChat 3.0]
ntwk has joined #riscv
<indyZ> I started drawing some RISC-V ascii/ansi/unicode art, for some reason. For all those little risc-v linux systems of the future. https://0x0.st/X-xK.png
jfsimon1981_b has quit [Remote host closed the connection]
mlw has quit [Ping timeout: 264 seconds]
KREYREN has joined #riscv
heat_ has joined #riscv
heat has quit [Read error: Connection reset by peer]
hightower4 has joined #riscv
hightower3 has quit [Ping timeout: 264 seconds]
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #riscv
KREYREN has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 264 seconds]
Guest42 has joined #riscv
<Guest42> Hello there. For some times, I'm interested in risc-v, but I dont success to figure out what it's really. And ... I don't understand. I feel like it's a CPU, but not really according to what I've read. Could someone explain it to me ? I'm lost
<sorear> why are you interested in risc-v?
<sorear> what do you know about the field?
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
<Guest42> coz it's an open source hardware, and I want to understand what it is
<Guest42> First, I thought that was a CPU, but it doesn't seem to be it
<Guest42> But a little bit
<sorear> risc-v is a specification, it's not hardware, open-source or otherwise.
EchelonX has joined #riscv
EchelonX has quit [Client Quit]
<indyZ> Guest42: It's an instruction set architecture (ISA), not a specific CPU. Like how Intel and AMD make chips that speak the X86-64 ISA, and Apple, Qualcomm, etc. make CPUs and SoCs that speak the ARM ISA
<indyZ> Guest42: But RISC-V is different, because it has open source licensing, and does not require any licensing to manufacture. It also has some interesting modularity properties
<indyZ> Guest42: Normally, if you want to make and sell your own X86-64 or ARM CPU, you must pay royalties to a company
EchelonX has joined #riscv
<indyZ> "must," depending on your jurisdiction :P
<Guest42> So, first thing : it's not a "real" thing, a "real" component
<Guest42> Ok.
<gurki> you still have to pay a bunch of royalties for all the peripherals, the sram generator, possibly the pdk, ...
<gurki> however, its a good start.
<Guest42> I've never dealt with ISA before. I understand how CPU works basically, but not really more. ISA specifies the registers, the instructions, the opcodes of the instructions and number of cycles it must take ?
<Guest42> Or it's more abstract ?
<indyZ> Guest42: It's the machine code language that the CPU speaks. So, your CPU doesn't directly understand JavaScript, Python, etc. It has to be compiled down to machine code. Assembly language is the human readable representation of machine code.
<Guest42> That I understand well.
<indyZ> Guest42: And operating systems are precompiled for different CPU architectures. Your phones and tablets run ARM OSs. Laptops and desktops are usually x86-64.
<indyZ> RISC-V is a CPU architecture
<indyZ> or an ISA
<indyZ> not a piece of hardware, but a specification for harware to speak
<indyZ> with its own unique assembly languge
<Guest42> Thanks, you fixed ideas about which I wasn't sure. But, still I have two questions. First : the asm instruction "add x1, x2" have a constant machine code according to the ISA ? In the spec, it doesn't specify the opcode of "add" : can it differ between implementations ? Second : it means that speaking about "the RISC-V chip" is not a correct thing
<Guest42> ? There are plenty ?
Andre_Z has quit [Ping timeout: 272 seconds]
ntwk has quit [Ping timeout: 268 seconds]
ln5 has joined #riscv
dzaima[m] has joined #riscv
<dzaima[m]> a RISC-V assembly instruction of "add x1, x2, x3" should produce the four bytes of "b3 00 31 00", and a RISC-V-compliant chip should execute those bytes as setting x1 to the sum of the integers at x2 and x3. How many cycles or seconds that takes is implementation(i.e. hardware)-specific. There is no "the RISC-V chip", same as there isn't a "the x86-64 chip" or "the aarch64 chip"
<indyZ> Guest42: There is no "The" risc-V chip, but it makes sense to speak about "a" RISC-V chip
<mps> and qemu
<mps> ofc, other emulators also
clever has joined #riscv
<Guest42> dzaima: where are the opcodes ? i don't find them in the pdf
<Guest42> It's written OP-IMM and SLLI for example, but no opcodes
<dzaima[m]> that's in the tables around "RV32/64G Instruction Set Listings" I think; I just looked at a disassembly
chripo has quit [Quit: ""]
chripo has joined #riscv
JTL has quit [Quit: .]
JTL has joined #riscv
<Guest42> oh thanks ! Thanks for all your answers, it solved my miscomprehension !
Guest42 has quit [Quit: Client closed]
luca_ has joined #riscv
luca_ has quit [Remote host closed the connection]
paddymahoney has quit [Ping timeout: 252 seconds]
paddymahoney has joined #riscv
heat_ has quit [Remote host closed the connection]
naoki has joined #riscv
<clever> at an assembly level, how do rv32 and rv64 differ?
<dzaima[m]> mostly the same (besides the obvious difference of acting on different-width data), but there are some exclusive instructions to both depending on extensions
<clever> ah, so if you never touch a 64bit value, some rv64 asm might wind up being compatible with an rv32 core?
<clever> and avoid the right extensions?
<clever> is there such a thing as an rv32 vs rv64 mode, or can an rv64 core be designed to accept both transparently?
<dzaima[m]> if you also don't ever rely on 32-bit wrapping arithmetic, and a bunch of questionability around sign- vs zero-extension, and probably other things, maybe
<clever> hmmm, i can see how a 32bit int like 0xffff_ffff, +1, would just become 0x1_0000_0000, but if you then do a 32bit store, would it truncate?
<dh`> the instruction encodings aren't quite the same
<dh`> it wasn't intended to be able to be both at once
<clever> ah
<clever> i was thinking that a design where the only difference is the width of a load/store, would simplify some things, rv32 and rv64 can share nearly all things
<clever> just have a spot in the opcode, that says 8/16/32/64, and 64 is just illegal on an rv32 core
<dzaima[m]> storing an unwrapped value might be okay, but using it as an address would not; and shifts & division could make the top bits reappear
<clever> ah yeah, and then things get more complex if you wanted to specify an expected width on the op
Trifton has quit [Quit: Client exited]
<clever> probably no need for it, but could you write a small stub, that can run on both rv32 and rv64, detects which one its on, and jumps to better code?
lagash has quit [Remote host closed the connection]
<dzaima[m]> https://github.com/riscv/riscv-opcodes lists the various opcodes, separated in common, rv32-, and rv64-specific encodings
lagash has joined #riscv
<clever> ah, perfect
DesRoin has quit [Ping timeout: 246 seconds]
DesRoin has joined #riscv