| Summary: | [patch] Add system features detection for Elbrus (E2K) | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Ivan Kuzmenko <kuzmenko.ivan1234> |
| Component: | *don't know* | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | a1ba.omarov, sezeroz |
| Version: | HG 2.1 | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Attachments: |
patch
patch (USE THIS INSTEAD OF FIRST ONE) |
||
|
Description
Ivan Kuzmenko
2020-12-26 14:43:09 UTC
Which gcc version supports __builtin_cpu_name()? I can't find documentation for it. Created attachment 4610 [details]
patch (USE THIS INSTEAD OF FIRST ONE)
(In reply to Ozkan Sezer from comment #1) > Which gcc version supports __builtin_cpu_name()? I can't find > documentation for it. const char* __builtin_cpu_name (void) That's a MCST lcc for E2K exclusive function which returns name of used CPU. These tests should be based on runtime environment, not compiler environment. It's completely possible to build SDL with MMX defined and run it on a processor that doesn't have MMX. Similarly for E2K, I assume that it's possible to compile SDL for x86 and then run it on that processor and it should detect the change at runtime. Look at the code in SDL_GetCPUCacheLineSize() for an example of dynamically changing results based on the CPU type. Sam, I'm afraid that there is no real need of doing so on E2K. E2K unlike Intel, doesn't have CPUID instruction and there is no real way to know, for example, to know L1 cache size. I didn't really heard about such instruction or special register. The only way is to rely on numbers given by Linux kernel at /proc/cpuinfo. (And even these numbers are actually hardcoded into kernel) 3DNOW/MMX/SSE support in E2K is done at compile-time, we can only use compiler intrinsics that are translated into native E2K code. It's directly supported by vendor and common way to re-use code written for Intel processors. There is no such thing as "MMX support" in runtime. If these macro values will be hardcoded into SDL binary, there can be also theoretical possibility that if software using SDL will be compiled with another compiler version that one that was used to compile SDL itself, the values returned by SDL_Has* functions can be outdated and not reflect what is really supported by compiler. For example, latest version of LCC (eLbrus C Compiler) does not support AVX2 but maybe it will be added in the future. What I do suggest though, is to give ports ability to define SDL_Has3DNOW/MMX/SSE function as macros for such architectures. Therefore compiler can enable and optimize branches in applications that rely on these functions. > For example, latest version of LCC (eLbrus
> C Compiler) does not support AVX2 but maybe it will be added in the future.
My bad, it does define __AVX2__ and seems implements it somehow.
Ah, I see. Okay, in that case, your patch looks fine to me, and I've added it: https://hg.libsdl.org/SDL/rev/9418952a355d |