Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Feb 2015 16:12:50 -0800
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>, Andrew Turner <andrew@fubar.geek.nz>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: FreeBSD/arm64 MACHINE/MACHINE_ARCH identification
Message-ID:  <54DD4182.7040505@freebsd.org>
In-Reply-To: <51DBDD85-A1FD-4A18-946D-FB78252BB845@bsdimp.com>
References:  <CAPyFy2A=Ev5gdYPKgEE0LS3-1sY%2BXmkZA7VCe71E6Fmbb=vMRw@mail.gmail.com> <607BF592-A09B-4DB4-9872-C9E63066AB57@bsdimp.com> <CAPyFy2Bgrap3TkFNuChyMC0Vwbjdt5FVW0ey03XtkK1iwNL1KQ@mail.gmail.com> <71E9C1B9-F819-420B-90A5-A36D58E71817@bsdimp.com> <CAPyFy2ATn5xgsvePCdvzqnyBS45izVHdL8yLaQQoKeJenSv9tg@mail.gmail.com> <228428CC-4042-4902-90A4-E7040F4BFFF5@bsdimp.com> <CAPyFy2BKzhiA4tbi-mXd6T114_zawmWTi3XbyXiUcgijQfHdyw@mail.gmail.com> <54DCE9B5.8040203@freebsd.org> <EC5AAE72-F553-4F31-8768-9854B6EE2C69@bsdimp.com> <20150212225655.26c865aa@bender.lan> <51DBDD85-A1FD-4A18-946D-FB78252BB845@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 02/12/15 15:11, Warner Losh wrote:
>
>> On Feb 12, 2015, at 3:56 PM, Andrew Turner <andrew@fubar.geek.nz> wrote:
>>
>> On Thu, 12 Feb 2015 11:37:38 -0700
>> Warner Losh <imp@bsdimp.com> wrote:
>>
>>>
>>>> On Feb 12, 2015, at 10:58 AM, Nathan Whitehorn
>>>> <nwhitehorn@freebsd.org> wrote:
>>>>
>>>> On 02/12/15 09:15, Ed Maste wrote:
>>>>>>> Oh - I don't care what directory Linux puts the kernel source
>>>>>>> in, only what's reported by uname.  As far as I can tell that
>>>>>>> has always been aarch64 for uname -m.
>>>>>>
>>>>>> Traditionally in Linux, they have been a matched set.
>>>>>
>>>>> Ok, it appears they may have abandoned this.
>>>>>
>>>>>>> We might decide that "uname -m" has to be aarch64 to match
>>>>>>> expectations of third-party software set by other operating
>>>>>>> systems. If that in turn means we have to move the kernel
>>>>>>> source, so be it.
>>>>>>
>>>>>> This one I’m not on board with. You’ve not made a compelling case
>>>>>> for it yet.
>>>>>
>>>>> That's why I said "we might decide" -- I'm not sure myself.
>>>>>
>>>>> However, there's no backwards compatibility concern here, we've
>>>>> never had a FreeBSD release that reports "arm64" for "uname -m".
>>>>> There's no reason for us to prefer "arm64" if everyone else uses
>>>>> "aarch64." Also, having arm64 for uname -m and aarch64 for uname
>>>>> -p seems a bit odd.
>>>>
>>>> I would assume uname -m would be "arm", not "arm64". Unless there
>>>> are fundamental platform differences you are baking in somehow,
>>>> which I don't know.
>>>
>>> arm would be a pleasing outcome, but looking at his WIP tree, it
>>> looks like it would be possible, but rather inconvenient to merge the
>>> arm64 bits back under arm and make them conditional.
>>
>> They are two different architectures. They don't share any assembly,
>> and the exception handling is different, both in exception types and
>> number of modes/levels.
>>
>> Along with this they only sort of share the special registers. The
>> method to access them is different, on 32-bit it is via a coprocessor
>> call where on 64-bit there is an instruction to get them by name.
>>
>> We may be able to share some of the new pmap code, however it would
>> need a lot of work as the virtual memory layout is different and it is
>> likely we will need to handle 64k granules on arm64 in the future.
>> Because of this any sharing there would need to be handled carefully.
>>
>> The interrupt controller and timer drivers will be shared, but these
>> are both devices and maybe they should be moved under sys/dev.
>
> Yea, rather inconvenient :)

Yes. For my own interest, how similar are 32-bit ARMv8 and 64-bit ARMv8? 
Is 32-bit ARMv8 just the same as 32-bit ARMv7?

It seems weird that the architectures would be that disjoint, but, if 
they are, I agree it makes sense more to treat them like ia64 and i386 
than a conventional 32-bit/64-bit port.

>> The two architectures will share very little code or headers. An ARMv8
>> core may be able to execute either 32 or 64-bit code (both are optional
>> so either one or both options will be enabled) so there is a case for
>> use to handle cc -m32, but I don't feel this is enough justification to
>> merge two otherwise different architectures just because they were
>> designed by the same company.
>
> We support -m32 on x86 where we have amd64 and i386 MACHINE values
> and directories today. I’m not sure how having either aarch64/aarch64 or
> arm64/aarch64 instead of arm/aarch64 would preclude -m32 from working.

It just makes it harder since /usr/include/machine isn't shared. There 
were a lot of hacks required to make that functional on x86, which you'd 
have to repeat.
-Nathan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54DD4182.7040505>