I have semi-concrete plans for such a port after I am done with
sparc64 and arm64 SSA.
That's really interesting!
PS: perhaps, instead of "vm" or "varch", the GOARCH should be named "dis" :)
I'd suggest GOARCH=n32k.
--
You received this message because you are subscribed to the Google Groups
For such questions you might be better off with
https://groups.google.com/forum/#!forum/golang-dev
Ok.
See https://groups.google.com/forum/#!topic/golang-dev/T1TwiiVZj_Q
and https://groups.google.com/forum/#!topic/golang-dev/svc7BAN5STA
You can learn how the porting was done for mips6 and s390
Is there any documentation available on how to add support
for new architecture?
I took a look at some files from `find src/cmd -iname "*amd64*"`
but didn't figure it out myself.
Viewing Rob's Talk [1] I got the impression that's not too hard.
[1] https://youtu.be/KINIAgRpkDA
--
You received
My experience in TARDISgo was that Name() was stable and correct,
see
https://github.com/tardisgo/tardisgo/blob/89fb026cf24627db3bddabb754fed9500b5cabcd/haxe/base.go#L62
Good to know, thanks for sharing.
My primary question is whether I should transform ssa.Value into another
type that allows
TL;DR: what's the best way to do SSA back-translation when using
x/tools/go/ssa?
I'm thinking about a Go compiler which accepts a subset of Go and emits
assembly for a microcontroller. Instead of going all the way from
lexing, parsing etc. I'd like to use x/tools/go/ssa.
In order to generate ass
