I’ve been experimenting with kernel programming in Swift and this required
disabling the use of the red zone. Currently Im compiling to ELF on Linux and
linking in my own minimal libc/libcpp with libswiftCore.a so its not using any
Linux libraries.
I did a PR for adding a '-disable-red-zone' option but it was suggested to add
a target triple instead of adding extra compiler options so I wanted to
discuss it. I don't think there is a specific target I can currently use so
I thought of adding one. Some suggested names I came up with:
x86_64-none-baremetal
x86_64-elf-none
I don't have a strong preference but I couldnt find anything that really matched
for an ELF kernel with no OS
On a related note about compiler options, what could be done about options such
as enabling/disabling certain instruction sets eg SSE or FP or other such
lowlevel options etc? These wouldn't necessarily always be on or off for a given
target but the programer may want the ability to fine tune for firmware and
embedded etc. Is there anyway this can be accomplished without adding lots of
compiler options? I understand not wanting to go the gcc route of having a large
option list.
swiftc has a hidden -Xllvm flag that passes options to the LLVM code generator. That might work for low-level options like instruction selection and maybe the red zone. It's not the right answer for production use, but it might be good enough for your experiments.
···
On Mar 28, 2016, at 11:16 AM, Simon Evans via swift-dev <swift-dev@swift.org> wrote:
On a related note about compiler options, what could be done about options such
as enabling/disabling certain instruction sets eg SSE or FP or other such
lowlevel options etc? These wouldn't necessarily always be on or off for a given
target but the programer may want the ability to fine tune for firmware and
embedded etc. Is there anyway this can be accomplished without adding lots of
compiler options? I understand not wanting to go the gcc route of having a large
option list.
I agree with Chris that it would be better in the abstract to tie these things to some
enumerable set of supported target configurations rather than accumulating huge
set of low-level options. I am, however, worried about that philosophical stance
committing Swift to recording a bunch of information for (apologies, but...) experiments
that are likely to be trivial or abandoned.
Now, for your specific case, it's not clear whether you're writing your own kernel
or just writing code that you'd like to embed within an existing kernel.
If you're targeting an existing kernel, that really is a known target with well-defined
ABI rules, and the most sensible encoding into a triple is just to say that the OS is
the kernel environment, something like:
x86_64-unknown-linux_kernel4.6
If you're targeting your own kernel, it's probably easiest to just adopt some existing
kernel's ABI unless you really get to a point that that's insufficient, and that leaves us
in the same situation.
I think it's completely reasonable in the abstract for Swift to support kernel triples
(ignoring for now all the bigger issues with running Swift in a kernel context).
There are two ways to do that: we can translate them to triples actually supported
by LLVM (plus necessary ABI-tweaking options like -disable-red-zone), or we can
get LLVM and Clang to accept the kernel triple natively and do sensible things with it.
The latter would be better; you'll need to bring it up on llvm-dev, though.
John.
···
On Mar 28, 2016, at 11:16 AM, Simon Evans via swift-dev <swift-dev@swift.org> wrote:
Hi
I’ve been experimenting with kernel programming in Swift and this required
disabling the use of the red zone. Currently Im compiling to ELF on Linux and
linking in my own minimal libc/libcpp with libswiftCore.a so its not using any
Linux libraries.
I did a PR for adding a '-disable-red-zone' option but it was suggested to add
a target triple instead of adding extra compiler options so I wanted to
discuss it. I don't think there is a specific target I can currently use so
I thought of adding one. Some suggested names I came up with:
x86_64-none-baremetal
x86_64-elf-none
I don't have a strong preference but I couldnt find anything that really matched
for an ELF kernel with no OS
On a related note about compiler options, what could be done about options such
as enabling/disabling certain instruction sets eg SSE or FP or other such
lowlevel options etc? These wouldn't necessarily always be on or off for a given
target but the programer may want the ability to fine tune for firmware and
embedded etc. Is there anyway this can be accomplished without adding lots of
compiler options? I understand not wanting to go the gcc route of having a large
option list.
Ah, I hadn’t seen that flag only the -Xcc one. I modified LLVM to accept a wildcard in the -force-attribute arg and “-Xllvm -force-attribute=.:noredzone” seems to do the right thing now
Thanks
Simon
···
On 28 Mar 2016, at 22:20, Greg Parker <gparker@apple.com> wrote:
swiftc has a hidden -Xllvm flag that passes options to the LLVM code generator. That might work for low-level options like instruction selection and maybe the red zone. It's not the right answer for production use, but it might be good enough for your experiments.