On 9/15/2024 2:09 PM, David Brown wrote:
On 14/09/2024 04:39, BGB wrote:
On 9/13/2024 10:55 AM, Thomas Koenig wrote:
David Brown <david.brown@hesbynett.no> schrieb:
>
Most of the commonly used parts of C99 have been "safe" to use for 20
years. There were a few bits that MSVC did not implement until
relatively recently, but I think even have caught up now.
>
What about VLAs?
>
>
IIRC, VLAs and _Complex and similar still don't work in MSVC.
Most of the rest does now at least.
>
Thanks - you know it far better than I do.
I use it fairly often.
Mostly VS2022 at present.
There are only two serious, general purpose C compilers in mainstream
use - gcc and clang, and both support almost all of C23 now. But it
will take a while for the more niche tools, such as some embedded
compilers, to catch up.
>
It is almost impossible to gather statistics on compiler use,
especially with free compilers, but what about MSVC and icc?
>
From what I gather:
GCC and Clang are popular for most mainline targets;
GCC is the dominant C compiler on Linux.
It is also far and away the dominant compiler for embedded systems - both embedded Linux and small embedded systems.
Albeit, ones with semi-popular CPU architectures.
Though, GCC and Linux kinda go together here.
Say, one isn't going to find Linux ported to targets outside the scope of GCC, and GCC isn't too interested outside the scope of targets that could potentially run Linux and see at least semi-widespread use.
MSVC is popular on Windows
Has been essentially freeware/fremium for over a decade;
Visual Studio has a fairly good debugger;
Targets limited to things you can run Windows on (x86, X64, ARM)
MSVC is mainly used for C++ - or for a C-like subset of C++.
I use it a lot for C, and it works well enough for this.
And, for native Windows development, generally gives a better experience than Cygwin or MinGW.
Granted, its interpretation of C differs slightly from GCC.
For the most part, the C dialect used by BGBCC also aligns more with MSVC, but did end up going more GCC-like on a few points, say:
LP64 rather than IL32P64/LLP64.
As, LP64 seemed more useful (and more typical) than LLP64.
Well, and also ended up adopting some amount of GCC's __attribute__ tags. For inline ASM, ended up going in a direction more like Borland/Watcom (albeit with the irony of using more PDP family ASM syntax, vs Intel x86 style).
But, there are differences, say:
I usually write:
MOV.L (R8, 16), R4
Rather than:
MOV.L 16(R8), R4
Or, if it were a more x86-like style:
MOV R4L, DWORD PTR [R8Q+16]
Where, say, address notation was/is:
(R8) //Load from R8
@R8 //Same as (R8)
(R8)+ //Post-increment
-(R8) //Pre-decrement
@R8+ //Post-increment
@-R8 //Pre-decrement
@+R8 //Pre-increment
@R8- //Post-decrement
Though, pre/post increment/decrement were dropped in BJX2.
They existed in SH-4;
They were "demoted" in BJX1-64C:
To free up encoding space, some operations were dropped/faked.
Where, BJX1 had several sub-modes:
32-bit mode: Extended SH-4, backwards compatible.
Had run some SuperH ports of Linux on it;
Had faked similar hardware interfaces to the SEGA Dreamcast.
64A/64B: Extended to 64-bits, but the ISA was modal
One would twiddle flags to select which instructions were available.
64C:
Mode had changed around some parts of the encoding to free up space.
Dropped/redid some stuff to avoid mode changes.
Was limited by the use of 16-bit instruction encodings.
And, the initial form of BJX2 was based on a "distillation" of 64C mode.
Albeit with a redesigned and much simplified set of hardware interfaces (and then ended up entirely dropping the use of auto-increment; except in a vestigial form that may be faked by the assembler).
I also went from "16-bit encodings with long-form 32-bit encodings" to "32-bit encodings with a 16-bit subset". But, the instruction encoding remains a little wonky as it originally evolved out of a prefix-encoding.
Then, there is a RISC-V sub-mode in BGBCC, which ironically still uses a similar syntax:
MOV.L (R20, 16), R10
Rather than:
LW X10, X20, 16
...
But, this was mostly because it was easier to keep the same basic ASM syntax, but then generate different instructions, than to write a different ASM parser.
.
TinyCC, popular for niche use, but limited range of targets;
x86, ARM, experimental RISC-V.
SDCC, popular for 8/16 bit targets;
SDCC has never been very popular. For the targets SDCC support, Keil (8051) and IAR (many small CISC targets) are far more common. But for these kinds of devices, you are never working in anything close to standard C anyway.
OK.
I had mostly heard of people using SDCC here.
CC65, popular for 6502 and 65C816;
That's getting /really/ obscure now. There are thousands of C compilers that are used, or have been used, for various microcontrollers. But if you sum all their uses over the last decade, it will not be close to 1% of the total use of C compilers.
This is mostly for the crowd still messing around with a few older systems:
Commodore 64/128
Apple II / II/C / II/E
Apple IIGS
NES and SNES
...
Also, some newer projects, like the "Commander X16" are also using CC65 (it was based around a 65C816 being used in a 6502 compatibility mode).
Where, AFAIK, GCC proper has little interest in these targets.