-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a thumbv4t-none-eabi target #74419
Conversation
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! Left a few remarks/questions.
src/librustc_target/spec/mod.rs
Outdated
@@ -676,6 +676,7 @@ supported_targets! { | |||
("powerpc64-wrs-vxworks", powerpc64_wrs_vxworks), | |||
|
|||
("mipsel-sony-psp", mipsel_sony_psp), | |||
("thumbv4t-nintendo-gba", thumbv4t_nintendo_gba), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CPU name is a bit odd as the trailing T means thumb support, but I guess this makes sense. You could run ARM instructions on the GBA though, right?
We do support one other ARMv4 target, armv4t-unknown-linux-gnueabi
, but I believe that defaults to ARM instructions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah both a32 and t32 are supported, and the system boots in a32 state, but we want as much of the code as possible to be compiled using t32, so we're defaulting to t32. With the instruction set RFC it'll be a lot easier to mix the two, but we'll still want the default to be t32 for any untagged functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh but I see what you mean with the trailing t
since the name already starts with thumb
.
i guess it could just be thumbv4-nintendo-gba
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I remember now!! it's called thumbv4t-nintendo-gba
because the LLVM target string that LLVM uses as the "basis" for this target profile is thumbv4t-none-eabi
, and so if they put "thumbv4t" then we should kinda just follow suit.
I remember that somehow I was able to run a command line thing and have LLVM or rustc print a list of all the "known" target strings, but I can't remember how to do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean rustc --print target-list
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorta like that, but I thought that I'd seen a similar command called on LLVM directly. I could be imagining that part.
I won't be online in the short term, can you take over r? @jonas-schievink (or delegate to someone else)? |
I'd like to standardise on using Nintendo's three-letter names for their own products, so this target would be |
This is one part where I have to disagree.
So I think that we should be using the far more common term Particularly, regardless of the spelling selected here, users will be able to use conditional compilation to share MMIO definitions across more than one target if they set things up properly. |
I'm planning on upstreaming a similar Switch homebrew target, and have been using Note that the 3DS uses Horizon as well, but has nearly no backwards compatibility. My thought is that if Nintendo has an internal fork of Rust (I've heard that they might?) then they could use |
@leo60228 I can't tell if that means you favor the common name for the env or the manufacturer name for the env, or some third option entirely. EDIT: though I don't think Nintendo is going to be putting out any new GBA games either way ;P |
I favor using, well, the OS name. However, unlike the Switch, the GBA doesn't have an OS, so... |
Well there's 4 strings:
If we want to have a way to separate the GBA, DS, and DSi targets (and they do share a lot of MMIO declarations) then we must use a different From there, the name of the overall target is just gluing together parts of the various target_foo strings. |
(Note: I've asked on Discord for some of the other homebrew folks from other consoles (DS, GameCube, Wii, N64) to come weigh in, since they also will assumedly want targets at some point, so perhaps we can find a consensus with enough eyeballs on the situation.) |
Hi, I'm one of the developers of Grand Star, a set of toolchains and libraries to target the Nintendo Wii. I agree with Lokathor's proposed naming scheme of I would have to strongly disagree with a proposed triples of: I'm unsure on the currently used Further - whilst I would love to use Great job with this @Lokathor and @ketsuban on the GBA target and also the PSP Community for the PSP target. |
This is the case for this particular target, but other codenames are more esoteric - "Nitro" ( Edit: Alright, I'm convinced on using |
`libnx` is used because I'm pretty sure that Nintendo has an internal rustc
fork with Switch support.
…On Fri, Jul 17, 2020, 1:53 PM Thomas Winwood ***@***.***> wrote:
I think that we should be using the far more common term GBA, especially
since the alternative is so similar that it can at first be thought of as
being just a weird misspelling of "gba".
This is the case for this particular target, but other codenames are more
esoteric - "Nitro" (NTR) for the Nintendo DS, for example. (That said,
the GBA SP and GBA Micro have different codenames to the original Game Boy
Advance - AGS and OXY - but would almost certainly not need separate
targets since they're architecturally extremely similar.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#74419 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB7X32K2SPQINMZHUMGNLCLR4CFY5ANCNFSM4O5EBNIQ>
.
|
Nintendo certainly uses LLVM, and at least one 3rd party has ported Rust to Switch before. However, I am not aware of Nintendo using Rust directly. In fact last year there was a person in the gamedev-wg discord who needed help trying to build a rust project for Switch using the official SDK, so unless it was added extremely recently I don't think Nintendo uses Rust. |
IMHO, target env name should not use Nintendo's model code designation. At least not by convention. If we look at all of Nintendo's model codes, we can see that most of them do not make sense to casual users:
Sources:
Even within this list, there is hardly any consistency; Super Famicom has a 4-letter code! There are three variations of Game Boy Advance hardware that all run the same exact games with no internal hardware differences. But each have their own unique model codes. I don't think it would be fair for Rust to use Finally, there is also the importance of meaning. While And then there is the insane 3DS family of devices with no less than six model variations. And just one model code for all of the following devices:
KISS, I think just using the common name makes the most sense. Or the common abbreviation, which is probably better. I don't even need to provide descriptions for any of these, since they are self-evident:
|
On Fri, Jul 17, 2020 at 01:23:46PM -0700, FenrirWolf wrote:
Both the 3DS and the Switch use an OS named Horizon, so there is a bit of a naming collision between something like `aarch64-nintendo-horizon-newlib` and `arm-nintendo-horizon-newlib`. The target arch is enough to distinguish them I guess but the OS's they run are still pretty different despite sharing the same name. That and at first glance it's not clear that those two targets even refer to the Switch and 3DS respectively. But maybe that's okay?
I think part of the problem is that "newlib" is not enough information
to specify the full runtime environment available to the problem.
Is it possible to share code and code paths between, say, the Switch and
the 3DS, just because they both run versions of the Horizon OS?
If it is, then I would suggest `aarch64-nintendo-horizon-switch` and
`arm-nintendo-horizon-3ds` or similar.
If it isn't, then I'd suggest leaving out `horizon` entirely. The only
reason to include it would be to support shared code.
If the fact that the target uses newlib is important, and there's
another variant that doesn't use newlib, then that could be included in
the name as well; for instance, `aarch64-nintendo-switch-newlib`.
|
Bikeshedding Switch targets is unrelated to this PR, do you know of a
better place for that?
On Fri, Jul 17, 2020, 6:25 PM Josh Triplett <notifications@github.com>
wrote:
… On Fri, Jul 17, 2020 at 01:23:46PM -0700, FenrirWolf wrote:
> Both the 3DS and the Switch use an OS named Horizon, so there is a bit
of a naming collision between something like
`aarch64-nintendo-horizon-newlib` and `arm-nintendo-horizon-newlib`. The
target arch is enough to distinguish them I guess but the OS's they run are
still pretty different despite sharing the same name. That and at first
glance it's not clear that those two targets even refer to the Switch and
3DS respectively. But maybe that's okay?
I think part of the problem is that "newlib" is not enough information
to specify the full runtime environment available to the problem.
Is it possible to share code and code paths between, say, the Switch and
the 3DS, just because they both run versions of the Horizon OS?
If it is, then I would suggest `aarch64-nintendo-horizon-switch` and
`arm-nintendo-horizon-3ds` or similar.
If it isn't, then I'd suggest leaving out `horizon` entirely. The only
reason to include it would be to support shared code.
If the fact that the target uses newlib is important, and there's
another variant that doesn't use newlib, then that could be included in
the name as well; for instance, `aarch64-nintendo-switch-newlib`.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#74419 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB7X32KYKBW6PX2IFPKCZADR4DFU3ANCNFSM4O5EBNIQ>
.
|
On Fri, Jul 17, 2020 at 03:42:04PM -0700, leo60228 wrote:
Bikeshedding Switch targets is unrelated to this PR, do you know of a
better place for that?
Not offhand. Zulip perhaps, and then a generalized version of the result
should end up in some kind of short "target naming guide"?
|
Folks are free to read the Zulip topic themselves but the take-away is that:
So I will update the PR to become a general |
Looks pretty good! Can we make this inherit from |
Looks good, I'll just approve as-is now. If there are any remaining issues they can be fixed later. @bors r+ |
📌 Commit ec9c8d8 has been approved by |
…arth Rollup of 4 pull requests Successful merges: - rust-lang#74333 (Deny unsafe operations in unsafe functions in libstd/alloc.rs) - rust-lang#74356 (Remove combine function) - rust-lang#74419 (Add a thumbv4t-none-eabi target) - rust-lang#74485 (More intra-doc links, add explicit exception list to linkchecker) Failed merges: - rust-lang#74486 (Improve Read::read_exact documentation) r? @ghost
Hurray! |
Pkgsrc changes: * Remove patches now integrated upstream, many related to SunOS / Illumos. * The LLVM fix for powerpc is also now integrated upstream. * Adapt those patches where the source has moved or parts are integrated. * The randomness patches no longer applies, and I could not find where those files went... * Provide a separate bootstrap for NetBSD/powerpc 9.0, since apparently the C++ ABI is different from 8.0. Yes, this appears to be specific to the NetBSD powerpc ports. Upstream changes: Version 1.47.0 (2020-10-08) ========================== Language -------- - [Closures will now warn when not used.][74869] Compiler -------- - [Stabilized the `-C control-flow-guard` codegen option][73893], which enables [Control Flow Guard][1.47.0-cfg] for Windows platforms, and is ignored on other platforms. - [Upgraded to LLVM 11.][73526] - [Added tier 3\* support for the `thumbv4t-none-eabi` target.][74419] - [Upgrade the FreeBSD toolchain to version 11.4][75204] - [`RUST_BACKTRACE`'s output is now more compact.][75048] \* Refer to Rust's [platform support page][forge-platform-support] for more information on Rust's tiered platform support. Libraries --------- - [`CStr` now implements `Index<RangeFrom<usize>>`.][74021] - [Traits in `std`/`core` are now implemented for arrays of any length, not just those of length less than 33.][74060] - [`ops::RangeFull` and `ops::Range` now implement Default.][73197] - [`panic::Location` now implements `Copy`, `Clone`, `Eq`, `Hash`, `Ord`, `PartialEq`, and `PartialOrd`.][73583] Stabilized APIs --------------- - [`Ident::new_raw`] - [`Range::is_empty`] - [`RangeInclusive::is_empty`] - [`Result::as_deref`] - [`Result::as_deref_mut`] - [`Vec::leak`] - [`pointer::offset_from`] - [`f32::TAU`] - [`f64::TAU`] The following previously stable APIs have now been made const. - [The `new` method for all `NonZero` integers.][73858] - [The `checked_add`,`checked_sub`,`checked_mul`,`checked_neg`, `checked_shl`, `checked_shr`, `saturating_add`, `saturating_sub`, and `saturating_mul` methods for all integers.][73858] - [The `checked_abs`, `saturating_abs`, `saturating_neg`, and `signum` for all signed integers.][73858] - [The `is_ascii_alphabetic`, `is_ascii_uppercase`, `is_ascii_lowercase`, `is_ascii_alphanumeric`, `is_ascii_digit`, `is_ascii_hexdigit`, `is_ascii_punctuation`, `is_ascii_graphic`, `is_ascii_whitespace`, and `is_ascii_control` methods for `char` and `u8`.][73858] Cargo ----- - [`build-dependencies` are now built with opt-level 0 by default.][cargo/8500] You can override this by setting the following in your `Cargo.toml`. ```toml [profile.release.build-override] opt-level = 3 ``` - [`cargo-help` will now display man pages for commands rather just the `--help` text.][cargo/8456] - [`cargo-metadata` now emits a `test` field indicating if a target has tests enabled.][cargo/8478] - [`workspace.default-members` now respects `workspace.exclude`.][cargo/8485] - [`cargo-publish` will now use an alternative registry by default if it's the only registry specified in `package.publish`.][cargo/8571] Misc ---- - [Added a help button beside Rustdoc's searchbar that explains rustdoc's type based search.][75366] - [Added the Ayu theme to rustdoc.][71237] Compatibility Notes ------------------- - [Bumped the minimum supported Emscripten version to 1.39.20.][75716] - [Fixed a regression parsing `{} && false` in tail expressions.][74650] - [Added changes to how proc-macros are expanded in `macro_rules!` that should help to preserve more span information.][73084] These changes may cause compiliation errors if your macro was unhygenic or didn't correctly handle `Delimiter::None`. - [Moved support for the CloudABI target to tier 3.][75568] - [`linux-gnu` targets now require minimum kernel 2.6.32 and glibc 2.11.][74163] Internal Only -------- - [Improved default settings for bootstrapping in `x.py`.][73964] You can read details about this change in the ["Changes to `x.py` defaults"](https://blog.rust-lang.org/inside-rust/2020/08/30/changes-to-x-py-defaults.html) post on the Inside Rust blog. - [Added the `rustc-docs` component.][75560] This allows you to install and read the documentation for the compiler internal APIs. (Currently only available for `x86_64-unknown-linux-gnu`.) [1.47.0-cfg]: https://docs.microsoft.com/en-us/windows/win32/secbp/control-flow-guard [76980]: rust-lang/rust#76980 [75048]: rust-lang/rust#75048 [74163]: rust-lang/rust#74163 [71237]: rust-lang/rust#71237 [74869]: rust-lang/rust#74869 [73858]: rust-lang/rust#73858 [75716]: rust-lang/rust#75716 [75908]: rust-lang/rust#75908 [75516]: rust-lang/rust#75516 [75560]: rust-lang/rust#75560 [75568]: rust-lang/rust#75568 [75366]: rust-lang/rust#75366 [75204]: rust-lang/rust#75204 [74650]: rust-lang/rust#74650 [74419]: rust-lang/rust#74419 [73964]: rust-lang/rust#73964 [74021]: rust-lang/rust#74021 [74060]: rust-lang/rust#74060 [73893]: rust-lang/rust#73893 [73526]: rust-lang/rust#73526 [73583]: rust-lang/rust#73583 [73084]: rust-lang/rust#73084 [73197]: rust-lang/rust#73197 [72488]: rust-lang/rust#72488 [cargo/8456]: rust-lang/cargo#8456 [cargo/8478]: rust-lang/cargo#8478 [cargo/8485]: rust-lang/cargo#8485 [cargo/8500]: rust-lang/cargo#8500 [cargo/8571]: rust-lang/cargo#8571 [`Ident::new_raw`]: https://doc.rust-lang.org/nightly/proc_macro/struct.Ident.html#method.new_raw [`Range::is_empty`]: https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty [`RangeInclusive::is_empty`]: https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty [`Result::as_deref_mut`]: https://doc.rust-lang.org/nightly/std/result/enum.Result.html#method.as_deref_mut [`Result::as_deref`]: https://doc.rust-lang.org/nightly/std/result/enum.Result.html#method.as_deref [`TypeId::of`]: https://doc.rust-lang.org/nightly/std/any/struct.TypeId.html#method.of [`Vec::leak`]: https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html#method.leak [`f32::TAU`]: https://doc.rust-lang.org/nightly/std/f32/consts/constant.TAU.html [`f64::TAU`]: https://doc.rust-lang.org/nightly/std/f64/consts/constant.TAU.html [`pointer::offset_from`]: https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.offset_from
(cc @ketsuban, one of the few other Rust users who programs for GBA.)
EDIT: This is now a more general
thumbv4t-none-eabi
PR! See this commentNow that the PSP officially has an official target within Rust, well as the lead of the
gba
crate I can't not add a GBA target as well.I know that the target tier policy isn't ratified and official, but I'll use it as an outline (cc @joshtriplett):
no_std
environment, without even a standard global allocator, so this adds no new code toalloc
orstd
.gba
crate (link). Well, the docs there are currently a little out of date, they're back on usingcargo-xbuild
, but the crate docs there will get updated once this target is available.I'm not fully confident in specifying the same linker script for all possible projects, so I'm currently just not giving a linker script at all, and users can continue to select their own linker script by using
-C
to provide a linker arg.I added the file, and added it to the
supported_targets!
macro usage, and I think that's all there is to do.