Closed p2mate closed 1 year ago
I just tried to compile using the latest Docker image, mrkits/rust-mos:latest
, and it works for me. I did this by compiling directly from the mos-hardware
directory with
cargo build --release --example c64-raster-interrupt --target mos-c64-none
yes, that's what I do as well. Using the following commits for my build:
mos-hardware 041e678404dd8a32ec81f8e7c70560d42a383bf9 rust-mos 1c70e860612a0f6c6a88584f17094e966ab1d06f llvm-mos-sdk 0777f80b84195eea83d626d33ab786b089c75c6d llvm-mos 9a8981cfd5c72c2e60151ce670cd56acc5b57148
I still haven't managed to build rust-mos and use only the docker image above which would have slightly older revisions. Did you try with that? I understand from other issues here, that later llvm-mos could be problematic.
Building the idiomatic plasma example in release mode also causes a miscompilation, even with the rust-mos
docker image and the latest commit (fdf984ddfc69c971c2da020f52542566761fc268) in mos-hardware
. The application starts but once the precalc is done the screen messes up.
Building in debug mode works fine, though!
I cannot reproduce the issue for the idiomatic plasma example; do you compile directly from the crate? I have only had issues with compilation in projects that use mos-hardware as a dependency (I suspect it has to do with LTO).
@mlund, this was compiled from a separate crate (based on mos-hardware-template
).
I tried turning off LTO (so opt-level ="s", lto = false, debug = 2
), but that resulted in:
LLVM ERROR: unable to legalize instruction: %13:_(s1) = G_FCMP floatpred(ord), %0:_(s32), %12:_ (in function: _ZN4core3f3221_$LT$impl$u20$f32$GT$8classify17hdbccd96cbb9378daE)
error: could not compile `core`
Turning on LTO again caused compilation to succeed, but the generated binary to fail. I put up the project here along with the resulting (failing) test.prg
binary. Maybe that can shed some light on things.
Thanks, @sagacity, I have similar issues when using mos-hardware as a dependency.
@sagacity It seems the problem may come from itertools iproduct
, see #18. Could you try to change the optimization level from s
to 2
or 3
in Cargo.toml
?
@mlund can we close it? Can you verify that all examples in mos-hardware work now?
Everything ok!
Great!
When compiling https://github.com/mlund/mos-hardware/blob/main/examples/c64-raster-interrupt.rs the resulting binary does not call main. See attached file. I don't think this is a bug in rustc, but possibly in LLVM or llvm-mos-sdk?
If I binary patch the jump at 0x837 to jump to 0x971 instead of 0x857, the program works.
output.txt