Okay so I'm still looking at this, but I saw that rust merged in LLVM 14, which is what my main port uses, and the rust branch was on 13. I'm going to get it all updated so there's only one p2 LLVM branch to avoid merge/feature issues like these.
@deets I've pushed a new branch, rust14 that's basically a copy of my llvm branch with rust's LLVM merged in. rustc compiles successfully, let me know if you are able to compile it and compile programs too. if all looks okay, I will merge rust14 into my master llvm branch so that all llvm features I add go to both and not create annoying conflicts.
I think there's actually something broken in the backend on that branch--I don't have any more time to look at it today but hopefully by the weekend I'll be able to track down where a specific change was made and fix the bug I'm seeing (that I know should be fixed)
I tried to at least build, got into weird issues with git (it somehow resetted the llvm-project-submodule !?!?, couldn't commit that then...), checked out a clean copy, updated llvm-project to rust14, annnd... it's not even building anymore.
error: attributes starting with `rustc` are reserved for use by the `rustc` compiler
--> library/core/src/../../stdarch/crates/core_arch/src/x86/eflags.rs:28:3
|
28 | #[rustc_deprecated(
| ^^^^^^^^^^^^^^^^
Sometimes I think I'd rather go into woodworking or some such...
I’m going to spend a few hours this morning cleaning things up to try to get it building. And I had to do some branch cleaning and resetting cause I f’d up (funny how I’m not supposed to swear on this forum yet everyone knows what I mean anyway…), so you’ll probably want to do a completely clean pull once I’m done. Stay tuned…
@deets said:
Sometimes I think I'd rather go into woodworking or some such...
As someone who does a lot of woodworking, programming is a lot cheaper on the wallet, but more expensive on the hair when you’re pulling it out!
Great to hear that you are on it again. I fiddled some more and thought I had fixed the ZEROX-instruction issue by declaring that instruction the exact same way you declared the SIGNX-instruction. Unfortunately now I'm getting errors that no registers can be allocated for all my assembly instructions, including the ones before... I'll call it quits for today & look at anything tomorrow if you had the chance of updating.
so something is quite broken--the rust installer panics when trying to copy the build compiler-- i've definitely screwed a lot of things up cause i don't know what I'm doing, so I'm going to nuke it and try porting from scratch. it was fairly minimal so I'll be able to recreate it quickly
okay so made some progress today and broke more stuff. I've gotten p2 set up on the "stable" branch because I think "master" had some issues. so I will be working out of there.
I'm not hitting the same zerox bug you hit--I added after I set up rust so I never tested it against the rust build. will try to hunt down why it's giving me an issue tonight.
I think I got it all working again. I can successfully compile the blink program from the first post, and the disassembly looks correct, but I haven't tried loading it yet. I would try a fully clean clone and build of the stable branch, as I did some rebasing and force-pushing. Let me know if you are able to compile anything.
I still need to fix the zerox issue--I just commented out the pattern for now. I'm not sure why I'm not seeing it in the usual clang build I do, but it should be fixed. I understand why it's throwing the error, but now how to fix it. Off to bed for now.
I tried it, the stable branch built, but I then got confusing errors about things to be needed to be compiled by the new compiler (sorry for the paraphrased error messages, I'm at work the next day). Then I remembered there were more steps to the whole thing, as you laid out in the beginning of this thread. Trying those failed for me, but I might have bungled something, as I was also repairing a coffee machine while waiting for 32 cores to churn through the code. I'll try afresh and report concrete errors (or hopefully success!)
Ok, gave it a shot tonight. After clean rebuild things looked good on the building side, with one small remark: your instructions about the compiler builtins contain a mistake, they are missing the --target p2.
But then compiling my code I got
✔ ~/Dropbox/projects/p2-rust-support/rt-test [master L|✚ 6…2]
20:23 $ cargo build --release
Compiling p2rt v0.1.0 (/home/deets/Dropbox/projects/p2-rust-support/p2rt)
Compiling rt-test v0.1.0 (/home/deets/Dropbox/projects/p2-rust-support/rt-test)
warning: unused imports: `_uart_init`, `_uart_putc`, `cogstart`
--> src/main.rs:7:12
|
7 | use p2rt::{cogstart, _uart_init, _uart_putc};
| ^^^^^^^^ ^^^^^^^^^^ ^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused variable: `data`
--> src/sd.rs:41:24
|
41 | pub fn xfer(&self, data: &[u8])
| ^^^^ help: if this is intentional, prefix it with an underscore: `_data`
|
= note: `#[warn(unused_variables)]` on by default
warning: field is never read: `si`
--> src/sd.rs:7:5
|
7 | si: Option<u8>,
| ^^^^^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
warning: field is never read: `so`
--> src/sd.rs:8:5
|
8 | so: Option<u8>,
| ^^^^^^^^^^^^^^
error: couldn't allocate input reg for constraint 'r'
--> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:49:18
|
49 | "dirl {pin}",
| ^
error: couldn't allocate input reg for constraint 'r'
--> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:13:18
|
13 | "wrpin {v}, {pin}",
| ^
error: couldn't allocate input reg for constraint 'r'
--> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:25:18
|
25 | "wxpin {v}, {pin}",
| ^
error: couldn't allocate input reg for constraint 'r'
--> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:37:18
|
37 | "wypin {v}, {pin}",
| ^
error: couldn't allocate input reg for constraint 'r'
--> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:60:18
|
60 | "dirh {pin}",
| ^
error: couldn't allocate input reg for constraint 'r'
--> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:71:18
|
71 | "fltl {pin}",
| ^
warning: `rt-test` (bin "rt-test") generated 4 warnings
error: could not compile `rt-test` due to 6 previous errors; 4 warnings emitted
✔ ~/Dropbox/projects/p2-rust-support/rt-test [master L|✚ 6…2]
20:23 $
Okay that makes sense. I made changes to the in-line asm register allocation to fix some bugs we were hitting in clang, probably need to set up rust library side to obey the new constraint. I’m out of town this week but might be able to hit it at some point.
If you have any pointers I could try & take a stab at it. Not that I'm not feeling like a monkey in front of a shakespeare sonata, but I recognize the odd pattern if I see it
I think the issue is in p2.rs (where you added the I32 to list of inline asm regs), you need to remove i8 and i16. This should force the compiler to upcast to i32, which is the only type supported in registers now.
Just a heads-up: I have capacity again and want to get back. The hiatus wasn't fully voluntarily either... let's just say formatting the wrong hard drive under Windows with your full Linux home partition can be filed under "motivational setback".
So the error wasn't that stupid typo, but a missing declaration for the bootstrap-compiler. I'm baffled how this has ever worked before, or if that's an indication I'm still confused as to what branch I should build. But for the record, this is the diff:
I haven’t looked at the rust side of things in a while, so it’ll take me a bit to wrap my head around how I actually got things working again. Sadly I don’t have as much time right now as my startup is in full swing, but maybe I can put a few hours to it this weekend to try to clean things up a bit and get my basic example working again
I haven’t made changes recently but I’ve been using it for quite a while now and aside from a couple of rare bugs I haven’t had the time to fix and the p2/c libraries being incomplete (but good enough for my work), it’s pretty stable. You can write full C++ programs (without the STL) and do a lot of interaction with Propeller hardware. Are there specific features you are thinking about?
Comments
Okay so I'm still looking at this, but I saw that rust merged in LLVM 14, which is what my main port uses, and the rust branch was on 13. I'm going to get it all updated so there's only one p2 LLVM branch to avoid merge/feature issues like these.
@deets I've pushed a new branch,
rust14that's basically a copy of my llvm branch with rust's LLVM merged in. rustc compiles successfully, let me know if you are able to compile it and compile programs too. if all looks okay, I will mergerust14into my master llvm branch so that all llvm features I add go to both and not create annoying conflicts.I think there's actually something broken in the backend on that branch--I don't have any more time to look at it today but hopefully by the weekend I'll be able to track down where a specific change was made and fix the bug I'm seeing (that I know should be fixed)
I'll have a go on the weekend, thanks for the effort!
I tried to at least build, got into weird issues with git (it somehow resetted the llvm-project-submodule !?!?, couldn't commit that then...), checked out a clean copy, updated llvm-project to rust14, annnd... it's not even building anymore.
Sometimes I think I'd rather go into woodworking or some such...
I’m going to spend a few hours this morning cleaning things up to try to get it building. And I had to do some branch cleaning and resetting cause I f’d up (funny how I’m not supposed to swear on this forum yet everyone knows what I mean anyway…), so you’ll probably want to do a completely clean pull once I’m done. Stay tuned…
As someone who does a lot of woodworking, programming is a lot cheaper on the wallet, but more expensive on the hair when you’re pulling it out!
Great to hear that you are on it again. I fiddled some more and thought I had fixed the ZEROX-instruction issue by declaring that instruction the exact same way you declared the SIGNX-instruction. Unfortunately now I'm getting errors that no registers can be allocated for all my assembly instructions, including the ones before... I'll call it quits for today & look at anything tomorrow if you had the chance of updating.
so something is quite broken--the rust installer panics when trying to copy the build compiler-- i've definitely screwed a lot of things up cause i don't know what I'm doing, so I'm going to nuke it and try porting from scratch. it was fairly minimal so I'll be able to recreate it quickly
okay so made some progress today and broke more stuff. I've gotten p2 set up on the "stable" branch because I think "master" had some issues. so I will be working out of there.
I'm not hitting the same zerox bug you hit--I added after I set up rust so I never tested it against the rust build. will try to hunt down why it's giving me an issue tonight.
I think I got it all working again. I can successfully compile the blink program from the first post, and the disassembly looks correct, but I haven't tried loading it yet. I would try a fully clean clone and build of the
stablebranch, as I did some rebasing and force-pushing. Let me know if you are able to compile anything.I still need to fix the zerox issue--I just commented out the pattern for now. I'm not sure why I'm not seeing it in the usual clang build I do, but it should be fixed. I understand why it's throwing the error, but now how to fix it. Off to bed for now.
I tried it, the stable branch built, but I then got confusing errors about things to be needed to be compiled by the new compiler (sorry for the paraphrased error messages, I'm at work the next day). Then I remembered there were more steps to the whole thing, as you laid out in the beginning of this thread. Trying those failed for me, but I might have bungled something, as I was also repairing a coffee machine while waiting for 32 cores to churn through the code. I'll try afresh and report concrete errors (or hopefully success!)
Ok, gave it a shot tonight. After clean rebuild things looked good on the building side, with one small remark: your instructions about the compiler builtins contain a mistake, they are missing the
--target p2.But then compiling my code I got
✔ ~/Dropbox/projects/p2-rust-support/rt-test [master L|✚ 6…2] 20:23 $ cargo build --release Compiling p2rt v0.1.0 (/home/deets/Dropbox/projects/p2-rust-support/p2rt) Compiling rt-test v0.1.0 (/home/deets/Dropbox/projects/p2-rust-support/rt-test) warning: unused imports: `_uart_init`, `_uart_putc`, `cogstart` --> src/main.rs:7:12 | 7 | use p2rt::{cogstart, _uart_init, _uart_putc}; | ^^^^^^^^ ^^^^^^^^^^ ^^^^^^^^^^ | = note: `#[warn(unused_imports)]` on by default warning: unused variable: `data` --> src/sd.rs:41:24 | 41 | pub fn xfer(&self, data: &[u8]) | ^^^^ help: if this is intentional, prefix it with an underscore: `_data` | = note: `#[warn(unused_variables)]` on by default warning: field is never read: `si` --> src/sd.rs:7:5 | 7 | si: Option<u8>, | ^^^^^^^^^^^^^^ | = note: `#[warn(dead_code)]` on by default warning: field is never read: `so` --> src/sd.rs:8:5 | 8 | so: Option<u8>, | ^^^^^^^^^^^^^^ error: couldn't allocate input reg for constraint 'r' --> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:49:18 | 49 | "dirl {pin}", | ^ error: couldn't allocate input reg for constraint 'r' --> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:13:18 | 13 | "wrpin {v}, {pin}", | ^ error: couldn't allocate input reg for constraint 'r' --> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:25:18 | 25 | "wxpin {v}, {pin}", | ^ error: couldn't allocate input reg for constraint 'r' --> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:37:18 | 37 | "wypin {v}, {pin}", | ^ error: couldn't allocate input reg for constraint 'r' --> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:60:18 | 60 | "dirh {pin}", | ^ error: couldn't allocate input reg for constraint 'r' --> /home/deets/Dropbox/projects/p2-rust-support/p2rt/src/lib.rs:71:18 | 71 | "fltl {pin}", | ^ warning: `rt-test` (bin "rt-test") generated 4 warnings error: could not compile `rt-test` due to 6 previous errors; 4 warnings emitted ✔ ~/Dropbox/projects/p2-rust-support/rt-test [master L|✚ 6…2] 20:23 $Okay that makes sense. I made changes to the in-line asm register allocation to fix some bugs we were hitting in clang, probably need to set up rust library side to obey the new constraint. I’m out of town this week but might be able to hit it at some point.
If you have any pointers I could try & take a stab at it. Not that I'm not feeling like a monkey in front of a shakespeare sonata, but I recognize the odd pattern if I see it
I think the issue is in p2.rs (where you added the I32 to list of inline asm regs), you need to remove i8 and i16. This should force the compiler to upcast to i32, which is the only type supported in registers now.
Hah. Interesting. Will give that a go asap.
OK, can confirm! It's a bit late for me to get into hacking today, but looking forward to flesh out my SPI driver!
Just a heads-up: I have capacity again and want to get back. The hiatus wasn't fully voluntarily either... let's just say formatting the wrong hard drive under Windows with your full Linux home partition can be filed under "motivational setback".
Edit: error was due to a stupid typo, never mind
So the error wasn't that stupid typo, but a missing declaration for the bootstrap-compiler. I'm baffled how this has ever worked before, or if that's an indication I'm still confused as to what branch I should build. But for the record, this is the diff:
modified src/bootstrap/lib.rs @@ -205,7 +205,7 @@ pub unsafe fn setup(_build: &mut crate::Build) {} ( Some(Mode::Std), "target_arch", - Some(&["asmjs", "spirv", "nvptx", "nvptx64", "le32", "xtensa"]), + Some(&["asmjs", "spirv", "nvptx", "nvptx64", "le32", "xtensa", "p2"]), ),I haven’t looked at the rust side of things in a while, so it’ll take me a bit to wrap my head around how I actually got things working again. Sadly I don’t have as much time right now as my startup is in full swing, but maybe I can put a few hours to it this weekend to try to clean things up a bit and get my basic example working again
I haven’t flashed yet, but I got building an ELF. I’ll report any other findings. Have you worked on clang?
I haven’t made changes recently but I’ve been using it for quite a while now and aside from a couple of rare bugs I haven’t had the time to fix and the p2/c libraries being incomplete (but good enough for my work), it’s pretty stable. You can write full C++ programs (without the STL) and do a lot of interaction with Propeller hardware. Are there specific features you are thinking about?