On Wed, 20 Aug 2025 19:21:13 +0000, Schmitt, Michael <[email protected]>
wrote:
>So here we have a big difference between an optimizing compiler and
>what an assembler program would do.
Realize C and GO are inefficient despite being optimizing compilers. They are
missing critical features, the least of which is good assembler integration.
You can include assembler but it is very painful. Only Unix is written in C.
IBM XL C is not a proper C because of IBM enhancements but is only somewhat
more efficient. You don't have a robust OS like z/OS with C.
MSVC is not a proper C and you do not have MS Windows without it because it has
a decent assembler.
int main() {
int counter = 0;
__asm {
mov eax, counter // Move the value of counter into EAX
inc eax // Increment EAX
mov counter, eax // Store the incremented value back into counter
}
C and GO ignored critical optimizing logic despite Google GO fixing some minor
C shortcomings.
1. Assembler code supported using the MSVC implementation. As an FYI, you can
use offset, length and other C variable attributes. Using zArch MVC makes this
a single optimized instruction.
2. No compile time support. Macros not supported by GO. C macros are not proper
macros. CONSTEXPR is an abysmal attempt. Only HLASM has true macros. Simply
put, the compiler cannot generate compile time code when the programmer does
not have the ability a tool to provide that logic.
Realize that x86-64 is the market CPU leading architecture. Linux uses between
an estimated 20% to 40% of x86-64 instructions / capabilities. Linux fails to
improve on x86-64. It's pops is 5,000 pages. zArch pops is only 2,000 pages but
a far more robust instruction set.
It's time for a new language that is an efficient hybrid of GO and assembler.
