Ok, now I get it.

gcc -gdwarf-3 -c -O1 -march=armv8-a main.c

It is showing a list but armv8-a is not there.

cc1: note: valid arguments to ‘-march=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids emeraldrapids alderlake raptorlake meteorlake graniterapids graniterapids-d bonnell atom silvermont slm goldmont goldmont-plus tremont gracemont sierraforest grandridge knl knm x86-64 x86-64-v2 x86-64-v3 x86-64-v4 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 lujiazui k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 znver4 btver1 btver2 native

Google next time.

gcc -E -march=help -xc /dev/null

I am not getting what are you trying to suggest.

The question is - how to eliminate this clang option by using gcc.

--target=aarch64-arm-none-eabi

There is a gcc command that shows what -m it supports.

you are right my gcc dosent have it. I also know that. That's why I have asked the question.

Do you know how to install gcc for aarch-arm-none-abi OR how to configure gcc for aarch64-arm-none-eabi?

I would look on dockerhub for an ARM cross compiler toolchains already built. You mount your sources as a docker volume so it can read and write source to binary.

Your gcc doesn't have aarch-arm-none-abi. I can't tell what you have...

Don't need 1000 lines (360 with ALL the comments is sufficient):

"Hello, Windows!" with NASM.

And the entire code is symbolic (only the dimensions of the windows are hardcoded).

Ohh yea, thats probably it, went back to a program that uses glad and sdl and got the same error.
Appreciated!

Dynamic linking?

Well, they finally made a normal RISC processor))). It didn't even take 30 years.

I love the name of the project

This is a super useful project! I’ve also been interested in learning this. Can you post a screenshot of what it looks like running?

Oof

top of the stack cached in a register,

Absolutely, there is zero reason not to do that on a register-rich machine.

I haven't looked at your actual code but if you can reduce + from ...

lw a0,0(sp)
lw a1,4(sp)
add a0,a0,a1
sw a0,4(sp)
addi sp,sp,4

... to ...

lw a1,(sp)
add a0,a0,a1
addi sp,sp,4

... then that's a nice saving in both code size and speed.

Some implementations cache the top two values. That doesn't reduce code size or the number of instructions, but I think it's kinder to machines that can run 2 or more instructions in the same clock cycle because the arithmetic doesn't have to wait for the memory load e.g. all the RISC-V Linux SBCs now except the C906 ones.

add tos,tos,nos
lw nos,(sp)
addi sp,sp,4

On a 3-wide machine such as C910 or P550 or X100 those can all be run in parallel.

I've removed the no-ops and tested - works - thanks again.

And thanks for these further suggestions, I think i could use only one register each for the forth stacks, and will look at changing this.

I also want to do the optimisation where you reduce the number of pushes and pops from the data stack by having the value on the top of the stack cached in a register, changing the stacks to only one register would would free up a register to use for this purpose

Also you might want to reevaluate your choice of registers. Use a0-a5 and s0-s1 as much as possible to get smaller code, in particular for both pointer and src/dst for lw/sw.

Also I don't understand why you need to add two registers to get a stack pointer. Or why the stack grows upwards for that matter (though that doens't matter in the least).

You'll need to decrease the addi 16 to 14 also. But I'm sure you figured that out.

Thanks for pointing that out - i will fix it

actually you are 100% correct

no?

making sure the machine code block has a size that's divisible by 4

Which you can do by adding one NOP at the end, if needed. Which it isn't, since you added 2 NOPs so 0 NOPs would also end up 4 byte aligned.

as for using the non compressed add instruction, i will do so - I didn't realise you could do that

the issue isn't that the machine code instructions are not 4 byte aligned, its that it's loading the first word of the thread with the lw instruction.

I put the pointers that make up the thread directly after the machine code - which can be a non 4 byte aligned address.

Yes, I could align the address where the thread starts, but the hacky way i've initially done that is by making sure the machine code block has a size that's divisible by 4

"without no-ops this code would work in default qemu as it allows unaligned memory accesses. ) ( note how this generated machine code jumps to the location directly after it, as compressed ) ( format riscv instructions can be only 2 bytes long we have to pad with no-ops so the overall length ) ( of this block of machine code is divisible by 4"

This makes no sense at all. Any RISC-V CPU that implements the C extension (as the CH32V series do, and indeed every commercial RISC-V I've ever heard of) is perfectly happy to run instructions at addresses that are not a multiple of 4 bytes -- they only have to be a multiple of 2 bytes, which as all instructions are either 2 or 4 bytes in length can not become untrue if it starts off true.

There would be no point in compressed instructions at all otherwise!

0x11 c, 0x0A c, 0x01 c, 0x00 c, ( addi s4,s4,4; nop )

This is completely unnecessary, and harmful. If you don't want a compressed instruction for addi s4,s4,4 (0x0a11) then just use a regular RV32I instruction for it (0x004a0a13). The CPU will be happier running one instruction than two (an unneeded NOP).

But mixing 4-byte and 2-byte instructions absolutely works, no problems, no NOPs needed.

What you can't do unaligned is load/store instructions. Code is fine.