--- FAIL: TestRISCVEncoder (0.02s)
	endtoend_test.go:221: 00184 (testdata/riscvenc.s:59)	AUIPC	$0, TMP: have encoding 970f0000, want ef000000
	endtoend_test.go:221: 00196 (testdata/riscvenc.s:61)	AUIPC	$0, TMP: have encoding 970f0000, want 6f000000
FAIL
FAIL	cmd/asm/internal/asm	0.223s

cc @bbarenblat

This does not compile:

//go:noinline
func maxInt32() int {
        return 1<<31-1
}

The compiler splts out reasonably assembly, which the assembler chokes on:

genssa maxInt32
   	00000 (add.go:4)	TEXT	"".maxInt32(SB)
   	00001 (add.go:4)	FUNCDATA	$0, "".gcargs·0(SB)
   	00002 (add.go:4)	FUNCDATA	$1, "".gclocals·1(SB)
   	00003 (add.go:4)	TYPE	~r0(FP), type.int(SB)
v7	00004 (add.go:5)	VARDEF	"".~r0(FP)
v4	00005 (add.go:5)	MOV	$2147483647, GP
v8	00006 (add.go:5)	MOV	GP, "".~r0(FP)
b1	00007 (add.go:5)	RET
   	00008 (<unknown line number>)	END
add.go:17: 00000 (add.go:5)	LUI	$524288, GP	immediate in from position cannot be larger than 20 bits but got 524288

It looks like our 32-bit immediate LUI + ADDI split is subtlety broken.

@josharian was right after all on https://review.gerrithub.io/#/c/300193/. :)

typecheck.go is failing after attempting to do a merge from master, and the failure is as expected. The registers used for the control value are clobbered between when they are set and when they are used.

Before the merge, the generated code works:

b14: ← b7
  v56 = SUB <bool> v9 v9 : T0
  v49 = SEQZ <bool> v56 : T0
  v57 = ANDI <bool> [1] v49 : T0
  v63 = BNE <flags> v69 v57
BRANCH v63 → b16 b18 (likely)

b16: ← b14
  v53 = LoweredNilCheck <void> v6 v18
  v54 = MOVDload <Blue> {autotmp_1} v2 v18 : GP
Plain → b17

b17: ← b16 b18
  v81 = Phi <Blue> v54 v61 : GP
BRANCH v63 → b21 b22 (unlikely)

v56 00041 (typeswitch.go:15)	SUB	T0, T0, T0
v49 00042 (typeswitch.go:15)	SEQZ	T0, T0
v57 00043 (typeswitch.go:15)	ANDI	$1, T0, T0
b14 00044 (typeswitch.go:15)	BEQ	T2, T0, 57
v53 00045 (typeswitch.go:15)	MOVB	(GP), ZERO
v54 00046 (typeswitch.go:15)	MOV	"".autotmp_1-8(SP), GP
b17 00047 (typeswitch.go:15)	BNE	T2, T0, 53

The control value v63 is the comparison between T2 and T0. The branch at b17 is fine because the intermediate code only sets GP.

After the merge, the code looks like this:

b14: ← b7
  v79 = SUB <bool> v9 v9 : GP
  v48 = SEQZ <bool> v79 : GP
  v82 = ANDI <bool> [1] v48 : GP
  v83 = BNE <flags> v13 v82
BRANCH v83 → b16 b17 (likely)

b16: ← b14
  v51 = MOVDload <Blue> {.autotmp_1} v2 v18 : GP
Plain → b18

b18: ← b16 b17
  v52 = Phi <Blue> v51 v41 : GP
BRANCH v83 → b21 b22 (unlikely)

v79 00041 (typeswitch.go:15)	SUB	GP, GP, GP
v48 00042 (typeswitch.go:15)	SEQZ	GP, GP
v82 00043 (typeswitch.go:15)	ANDI	$1, GP, GP
b14 00044 (typeswitch.go:15)	BEQ	T1, GP, 56
v51 00045 (typeswitch.go:15)	MOV	""..autotmp_1-8(SP), GP
b18 00046 (typeswitch.go:15)	BNE	T1, GP, 52

Now the control value v83 is the comparison between T1 and GP. The intermediate code changes GP, so the branch at b18 is not correct.

Reminder for later, once everything has stabilized.

Quoting/modifying golang/go#16362:

The assembler document has a section at the end summarizing architecture-dependent details.It needs one for the new RISC-V port.

At the least, the order of inputs to LUI is wrong. Once we're convinced we have pretty good coverage, it'd be good to review all the instructions and make sure we're happy with them. And--in a first for the Go assembler--document them!

Some RISC-V implementations will be more dependent on static branch prediction. We can be friendlier to them by moving the morestack call to the end of the function, so that the initial ld; bgeu is a not-taken forward branch. Look at what cmd/internal/obj/x86.stacksplit is doing, there are subtleties with pcdata and stack adjustment that need to be handled to keep GC happy (just copying the original x86 commit is not enough).

RISC-V pushes the As constants over the 16-bit limit, which forced us to upgrade obj.As to int32. It would be nice to get back to int16.

What version of Go are you using (go version)?

go version go1.10.3 linux/amd64

What operating system and processor architecture are you using (go env)?

Ubuntu 18.04 GOARCH="amd64"

What did you do?

Follow quick start instructions: ./make.bash

What did you expect to see?

What did you see instead?

# runtime/internal/sys compile: unknown architecture "riscv"

inst.go says "// Automatically generated by parse-opcodes". It looks like parse-opcodes is probably https://github.com/riscv/riscv-opcodes, but I don't see a Go code generator there. At a minimum, we should document how to re-generate the file (including fixing riscv/riscv-opcodes#6).

Better would be if riscv/riscv-opcodes#7 got fixed, at which point the json and generation script could live in this repo, where it could be easily modified and re-run by developers, and where changes to both script and json would be tracked and code reviewed.

cc @bbarenblat (I don't seem to have github permissions to assign issues)

Signal handling got refactored by Ian during the 1.8 cycle. The runtime defs need updating:

# runtime
runtime/os_linux.go:317: undefined: stackt
runtime/os_linux.go:387: undefined: stackt
runtime/os_linux.go:391: undefined: sigctxt
runtime/signal_sighandler.go:30: undefined: sigctxt
runtime/signal_sighandler.go:109: undefined: dumpregs
runtime/signal_unix.go:205: undefined: sigctxt
runtime/signal_unix.go:217: undefined: stackt
runtime/signal_unix.go:237: undefined: sigctxt
runtime/signal_unix.go:320: undefined: sigctxt
runtime/signal_unix.go:444: undefined: sigctxt
runtime/signal_unix.go:496: undefined: sigctxt
runtime/signal_unix.go:577: undefined: stackt
runtime/signal_unix.go:611: undefined: stackt
runtime/signal_unix.go:622: undefined: stackt
runtime/signal_unix.go:635: undefined: stackt

Hi,

I notice that this repo hasn't been updated for a while, and wonder what the porting progress into mainline is?

Actually I have a patch, aiming at completing the missing relocation types in current src/debug/elf/elf.go. But I am still trying to figure out the usage of GerritHub. :)

Thanks.

In the file riscv.md:

Setup:

```sh
$ export GOROOT_BOOTSRAP=/path/to/prebuilt/go/tree

The BOOTSRAP should be BOOTSTRAP.

• A real NOP (ADD $0, ZERO, ZERO), not the plan9 pseudo-op NOP. What should it be called?
• SEQZ (SLTIU rs, $1, rd) and friends. Have to decide whether to try to match x86 names.
• Read through the spec's commentary and look for others.

Right now we assign REG_FP = REG_S0, though it is never initialized or updated, so attempts to use it segfault. Taking a quick look at the rest of the toolchain, it looks like other arches might actually treat it as a psuedo register that doesn't have a real assignment at all?

This would better match the spec, and SCALL is not a standard plan9 asm instruction.

this repo is now outdated. the port is being upstreamed in 1.14. we should update the readme prominently to tell people that and then archive this repo.

i don't have any permissions in this repo. i can't even close issues that i've answered. :(

so I guess @bbarenblat or @prattmic will have to do this.

Dear community,

We want to build go programes for riscv, but we want it to run on bare metal.
However I am not able to find any document specifying explicitly whether bare metal (without OS) is supported or not.
Any reply would be much appreciated!

Best Regards,
Xiang

progedit starts with:

    // Ensure everything has a From3 to eliminate a ton of nil-pointer
    // checks later.
    if p.From3 == nil {
        p.From3 = &obj.Addr{Type: obj.TYPE_NONE}
    }

Past experience suggests that it's worth deal with the nil checks on From3 and avoiding the allocations, as a matter of performance.

Attempting to compile strconv/atof.go:

strconv/quote.go:533: 02193 (/Users/josh/go/riscv/src/strconv/atof.go:425)	MOV	$3407386240, T2: constant 3407386240 too large; see riscv.rules MOVQconst for how to make a 64 bit constant: immediate does not fit in 32-bits: 3407386240

That constant (conspicuously) is 32 bits long. Either the assembler or riscv.rules is wrong for this edge case.

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

Not sure. Transition between pre-1.15 (uncertain) and 1.15.

What operating system and processor architecture are you using (go env)?

Host compiler (Clang) is on x86_64 Ubuntu

What did you do?

Nothing spectacular. Just tried to compile https://go.googlesource.com/gollvm/ - and it is no more compiling, after some files where removed, for libgo project.

I am not claiming that there where some direct support of RISC-V arch (gollvm language front-end wasn't ever compiled for running on RISC-V). However LLVM's backend could support it (I was able to generate debug and release builds, for that) and running llvm-goc, on Linux, could potentially target RISC-V arch.

What did you expect to see?

build.ninja would be generated.

What did you see instead?

CMake exit with an error.

Here is my detailed explanation: golang/go#40528 .
I don't think that the maintainers of that project has any bandwidth to deal with RISC-V support - so you might help with that.

Ivan

As part of an effort to get @sorear's changes in, so we can all move forward, I'm going to note some codereview items here that can be reasonably done as follow-up changes instead of blocking submission.