Reply to post: Re: It bears repeating: Building a CPU that runs C fast considered harmful.

Re: It bears repeating: Building a CPU that runs C fast considered harmful.

Nothing you said makes any sense... Allow me to try and clear up some misunderstandings.

Byte addressing has absolutely nothing to do with the language you program in. There is no reason at all that a "C compatible CPU" (what is that anyway?) needs to have byte addressing in hardware, or that other languages don't need it. If a CPU has a 64bit data path, and retrieves 64 bits of data from RAM at a time, you can still easily address a single byte. You just need to select the right byte in the 64bits of data. Which can be done inside the CPU, or inside the compiler. x86 assembly for instance lets you access registers as bytes (eg. AH register) or larger (AX for 16 bits, EAX for 32 bits etc) even if it's a 64bit CPU.

Why would byte addressing double the size of pointers? It increases the size of a pointer by 1 bit... If you would make a CPU that can only access 16 bits at a time instead of 8 bits, all you need to do is remove one address line (A0) from the CPU, but that still has nothing do to with the size of a pointer. There are lots of reasons to access individual bytes, regardless of the programming language, so pointers would still need byte access. Even if the programming language does not have C-style pointers, you still need to be able to access information on byte level (stupid examples: ASCII text, serial ports, MPEG video, graphics, ...).

Java has no "pointers", so that statement does not make sense. The amount of memory Java can access is limited by the CPU it runs on, it has nothing to do with the language.

Alignment of objects has nothing to do with pointer size. At all. Totally unrelated. On a 64bit processor, objects are likely aligned on 64bit boundaries. That does not mean pointers only point to 64bit based addresses. If anything the pointer size would be related to the smallest variable size, not alignment. In C and most other languages, a byte is the smallest variable size, so pointers still need to point to individual bytes. Java for instance has a byte primitive, which (surprise surprise) is 1 byte big. So, Java works with byte addressing regardless of what you claim. Any system that can run Java needs to be able to address individual bytes. That can be done in software (in the jvm) or in hardware, that is irrelevant.

The (standard) JAVA jvm is written in C by the way. So if your processor can't run C, it can't run Java. Unless it has a baked in jvm, but then it would only be able to run jvm based languages and nothing else. Those do exist, but they are understandably not very popular.

Garbage collection is not part of the C standard, that is true. But lots of areas where C is (still) used don't actually want garbage collection, because there are lots of problems with it (slow, not deterministic, not safe, ...). In anything (hard) real time, garbage collection is unwanted. You will find that none of the so called low level languages (the ones operating systems and the like are written in, like C, C++, rust) have a garbage collector.

Claiming that supporting C doubles the transistor count is completely ludicrous. You jump from doubling pointer sizes (which is already wrong) to doubling transistor count, but there is absolutely no linear relation between them. Even if you mean doubling the amount of supported RAM that would only mean adding one address line which is only a tiny fraction of the total amount of transistors used to make a CPU.

Your statement of "48bit address spaces are larger that anyone will use" is proven wrong by the current Intel processors, they already have 52 address lines (but I bet you'll claim that's because they support C, right? Wrong! It's determined by the amount of RAM they can address).

Claiming that implementing garbage collection in C is impossible is again baseless. It is possible to write anything in C. Since it is a very low level language that is close to the hardware, there is nothing you can't write in C. It might not be the most efficient way to do it in terms of effort, but it most certainly is possible. The Java garbage collector for instance is written in C... It's not a very good one, but still.

I'm not sure where your thinking comes from, but it seems to me you have a lot to learn about CPU design. It's a very interesting field but I'm afraid you'll have to let go of a lot of misconceptions if you want to study it further... I hope I cleared some of them up for you.