x86_64 port and BSP (GSoC 2018)

Amaan Cheval amaan.cheval at gmail.com
Mon May 14 13:20:30 UTC 2018


On Mon, May 14, 2018 at 6:08 PM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 14/05/18 14:34, Joel Sherrill wrote:
>>
>>
>>
>> On Mon, May 14, 2018, 7:12 AM Sebastian Huber
>> <sebastian.huber at embedded-brains.de
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>
>>     On 14/05/18 14:09, Joel Sherrill wrote:
>>     > On Mon, May 14, 2018, 7:07 AM Sebastian Huber
>>     > <sebastian.huber at embedded-brains.de
>>     <mailto:sebastian.huber at embedded-brains.de>
>>     > <mailto:sebastian.huber at embedded-brains.de
>>     <mailto:sebastian.huber at embedded-brains.de>>> wrote:
>>     >
>>     >     On 14/05/18 13:14, Amaan Cheval wrote:
>>     >     > Regarding naming, how about we settle on something like
>>     >     > "bsps/amd64/amd64_generic", borrowing from how the riscv
>>     target is
>>     >     > structured?
>>     >
>>     >     In case you want to name the new architecture "amd64", then
>>     the tool
>>     >     chain should be renamed as well, currently we have
>>     >     x86_64-rtems5-gcc, etc.
>>     >
>>     >
>>     > The target is picked after the GNU target name. We have always
>>     agreed
>>     > with the GNU target name.
>>
>>     Ok, makes sense. Will the new stuff support the 32-bit instruction
>>     set?
>>
>>
>> I have no idea. On a native Linux or BSD toolset, does -m32 produce the
>> same 32 bit ABI code as i386-elf?
>>
>> I am pretty sure our x86_64 toolset does not have the 32 bit multilibs.

+1 from cursory checks earlier, they don't.

>>
>> In fairness, even though x86_64 appears to be the canonical name, maybe
>> amd64 is an acceptable alias. Internally, the tools use x86_64 though.
>>
>> I would prefer to stick to the canonical name internally.
>
>
> All targets use the canonical name up to now (riscv is a small exception
> with riscv32 and riscv64). I would not make an exception for the current
> Intel architecture invented by AMD. Either name it x86 (if there is a
> potential 32-bit support, why would you use it?) or x86_64.
>

Naming it x86 right now, with 32-bit support not being in the scope of
the summer's project at the moment would only cause confusion IMO,
since we'd have both i386 and x86. In the situation that we do want to
add multilib support and whatnot, we can rename later and make x86_64
a BSP within the x86 arch, right?

For now, do we all agree to x86_64 as the arch, and x86_64_generic as the BSP?

>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



More information about the devel mailing list