Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: BGB Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Fri, 13 Sep 2024 21:39:36 -0500 Organization: A noiseless patient Spider Lines: 71 Message-ID: References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <2024Sep10.101932@mips.complang.tuwien.ac.at> <2024Sep11.123824@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 14 Sep 2024 04:39:47 +0200 (CEST) Injection-Info: dont-email.me; posting-host="cc93f9ab63efe860553c151b195d90ed"; logging-data="1336898"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19q1s15h6u/6+TGHI7Xz3NL+G7L6LDw/gk=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:bvF/3BGKCc0qkjLY13GXF1MgDBI= In-Reply-To: Content-Language: en-US Bytes: 4063 On 9/13/2024 10:55 AM, Thomas Koenig wrote: > David Brown 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. >> 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. 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). TinyCC, popular for niche use, but limited range of targets; x86, ARM, experimental RISC-V. SDCC, popular for 8/16 bit targets; CC65, popular for 6502 and 65C816; ... For my project: I am currently using GCC to target RISC-V; I am using BGBCC for BJX2 (Baseline and XG2). As for "mystery bug": Seems a minor and subtle typo in some of the instruction decoding code had broke my emulator pretty hard, in a way that mainly manifested when virtual memory was enabled... (Seems what bugs remain in the VL core are likely unrelated). The register mapping rules for XG2RV Mode have been changed: R0: ZR / PC R1: L1 R2 / R3: GPRs R4..R13, same R14: GBR (GP) R15: SP So, XG2RV mode will now be capable of expressing both the BJX2 and RISC-V ABIs (with a register remap), and will now be "register compatible" with RISC-V mode. Main difference between the modes will be that GBR/SP and R2/R3 will switch around, but this remapping can likely be faked in the assembler for the reworked XG2RV mode. This should hopefully also make it "less useless". There was a tweak to the register mapping rules for RV Mode, but it serves a few purposes: Will allow for trying to mimic the Linux layout for the "task_struct"; Will allow the RV side of things to express the BJX2 ABI if needed (by having the main ABI relevant registers available).