Perhaps I didn’t make it clear, but I won’t deny Raspberries Pis to be a high-value target and host platform. I just wanted to say that supporting Raspberry Pi as a host it self doesn’t involve embedded programming. The features you listed that makes Pi different don’t seem to be utilized by any part of the toolchain — so that’s what we need to support as a target instead of a host.
I understood that. My comment was meant to reflect that there is great value to doing the entire cycle on the Pi itself. For example running lldb with local copies of source directly on the the embedded device is something that most embedded programmers would love to do but they can't bc of the limitations of the embedded processor. The Pi can do that, and it can be done with the community-supported tool chains today. seems a shame not to continue to do so.
@rvsrvs I think the point is that Swift wants to have full support for all ARM64 hosts. One of the hosts that we should support fully is the Pi: the Swift project should aim to provide it as good an experience as any other host.
I think the point that @stevapple was making is that we probably don't need to consider the Pi as some kind of embedded target (despite its embedded-like capabilities) due to its relatively strong performance. Instead, it should be considered a fully-fledged ARM64 host, pretty much like any other.
The comment I actually wanted to make though is about @stevapple's last point regarding
From my understanding, this is a major reason why
StringProtocol exists and why many stdlib algorithms are written against it rather than
String proper. Swift could allow disabling
String entirely as a build-time option for embedded targets and have
AsciiString or something equivalently lightweight instead. String literals could result in
AsciiStrings in that build mode, and they could be checked for ascii conformance at compile time in the same way
UInt8(999) fails at compile time now.
I wouldn't want to have the semantics and capabilities of
String pulled out from under me in embedded mode – this would be especially problematic in library code. On the other hand, algos written against
StringProtocol should be expected to work on
AsciiString too. What would be nice is to align on the requirements of that type for embedded targets and not have 5 different "low power" types, but hopefully just 1 or max 2.
i think that misses the host/target distinction that @stevapple was making.
if i understand you correctly you are saying the Pi should be supported as host and target (which is the point i was making) @stevapple was saying the pi shd be only a target, ie the swift compiler toolchain shd not run itself on the pi, rather executables generated on toolchain hosts for the pi would be sufficient.
My point is to say that Pi developers for embedded systems like swift on the Pi precisely bc the entire toolchain can be run there.
Well, I believe I never had said that.
Yep, that’s what I meant to express:) Thanks @Geordie_J to bring it up more clearly.
@stevapple My apologies for misstating your position. I seem to have had it backwards.
Let me see if I can be more clear in what I'm saying though, because I'm still in disagreement with the last post above: the target/host distinction being drawn in this thread doesn't really work for folks developing on the Pi and is in a real sense a step backwards.
Most Pi developers would prefer to be a target like other embedded processors, provided the support were there. It is true that due to tireless efforts of a few people in the community, you can run the entire Swift compilation toolchain on the Pi. And it is true that you can't do that with other embedded devices - but that is not a good reason to classify the Pi as a "host" and not a "target" or not "embedded", it needs to be viewed as both.
Members of the community, myself included, went to the trouble of creating cross-compilation toolchains from the Mac to the Pi for a really good reason - we weren't productive using the Pi as a host, we wanted it as a target. And the reason we wanted it as a target is the same as the reason that Apple created x-compilation tools targeting the iPhone, even though the iPhone would be just as reasonable a host as the Pi: performance. It's just painfully slow to do all your development on the Pi, relative to being able to do it on the Mac. Just as it would be painfully slow to do all your compilation, debugging, and testing for your app directly on your phone. In fact, every argument that one could make about the Pi not being an embedded target and really being a host is true of the iPhone, bc the iPhone is actually far more powerful than even the Pi 4, not to mention the various flavors of 3 and Zero.
If I run the entire toolchain on the Pi for my projects, compilation build/deploy/test cycle times go up by easily an order of magnitude. And frequently the compiler runs out of memory and crashes. And test suites take forever to run. Cross-compilation and unit testing of code Pi code on the Mac is amazingly faster once you are able to perform the magic to make it work. The problem today is that working that magic is a very obscure skill.
There are certainly plenty of people in the Pi/Swift dev community who do do everything on the Pi. But everyone I know in that community would be ecstatic if Apple were to provide even a minimally similar experience to Pi development that they provide to iPhone development. Let me hook up my Pi to my Mac via a USB cable, do all compilation on the Mac, deploy to the pi with a button press and launch a debugger that worked perfectly across the wire and let me debug Pi GPIO programs from my Mac and I'd never want to run the swift toolchain on the Pi again. However, this seems an unlikely prospect. Now, do I expect to ever see Apple provide a Pi simulator like they do for all their own devices? Not in the least. But there are some very nice intermediate options available especially in the form of x-compilation.
Yes, the Pi can be a host for the compiler and that's nice... but not particularly useful. And if classification of the Pi as a "host" means we are excluded from the tools available to "targets", I for one am going to be really disappointed because it sort of seems to me to miss what the community really needs.
My point here and in the call has been that, for the Pi to have a good swift dev experience, we need cross-compilation, remote debugging, host-based testing tools and smooth deployment, just like other embedded devices. And we need those x-compilation tools much more than we need the on-device tools (except maybe for lldb and if that worked reliably over the wire, not even then). But for now, the best we can do in many cases is to use the Pi as its own host. But that's a second-best option IMHO.