[fpc-devel] The new XMM intrinsics

[Sven Barth]

Am 18.01.2020 um 13:18 schrieb Florian Klämpfl:
> Am 18.01.20 um 12:53 schrieb Sven Barth via fpc-devel:
>> Am 18.01.2020 um 12:46 schrieb Florian Klämpfl:
>>> Am 16.01.20 um 23:22 schrieb J. Gareth Moreton:
>>>> Hey everyone,
>>>>
>>>> Maybe I'm being a bit pedantic with this, but must we abide by 
>>>> C/C++ standards and go by the name __m128 etc. for the 128-bit data 
>>>> type? 
>>>
>>> They can be added additionally. After some thinking, I came to the 
>>> conclusion we should first go with the same naming C uses (as we do 
>>> in every library header meanwhile), on top of this some more 
>>> pascalish way can be added.
>> But these are not library headers. These are going to be base 
>> language types and I don't see a real reason to follow the C 
>> convention here, only because they were the first and other 
>> developers might easily recognize them this way. As mentioned in my 
>> other mail we don't have the name conflict problem that C/C++ faced 
>> when adding these types.
>
> * there is a lot of example code out there for C, and same naming 
> makes it much easier to use it in FPC. Actually, I encountered this 
> already when playing with some C examples from SO. Even though I am 
> very familiar with this topic, I ended up to put the C code into 
> godbolt to find out which assembler instructions it uses and then I 
> tried to find the right FPC intrinsics (we don't :(). Lesson learned :)

I don't necessarily mean the intrinsics (though we could still declare 
them as e.g. x86_mm_extract_epi32, so that it's clear that A) it's x86 
only and B) that they have the same name part as the C examples). But 
the type names should be more Pascal like. For day to day use I imagine 
most of the intrinsics to be hidden by normal Pascal language code (e.g. 
somearray := somessevar calling the corresponding intrinsic). However 
the types will be used more (also we can document that these are 
equivalent to the corresponding C types). And for those that want C 
compatible type names we can always add aliases to the ctypes unit.

> * finding a systematic, pascal-like naming scheme is not easy, there 
> are countless cases to consider
> * they are part of the system unit, so they are prone to name clashes 
> (this is something I were thinking to try: if they could be moved 
> without too much hazzle into a seperate unit)

But those name clashes are restricted to the System unit which, while 
not that small, is still finite. The C/C++ devs had to consider all code 
out there due to the missing concept of namespaces.

Regards,
Sven