[fpc-devel] The new XMM intrinsics

[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 :)
* 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)