Feasible? Very. Detrimental to performance on average, though. I remember sitting through many LP64 versus ILP64 meetings almost 20 years ago when the transition to 64-bit was upon us. (At least upon us CPU designers...) Turns out 64 bit ints cause memory usage and cache pressure that outweigh the benefits.
A lot of people don't think about the effect of design decisions on cache performance. Die area devoted to cache can't be used for other things, and the process of filling the cache with larger entities impacts memory bandwidth utilization. So 64 bit ints when mostly you only need 32 bits can turn out to be a loser. This is also why the pendulum has swung back to CISC -- more functionality crammed into smaller cache footprint, and the compilers are much better at targeting CISC instruction sets than they were at the height of RISC.
I disagree with the last part of your comment: many RISC added a 16 bit extension of their ISA.. So you can have RISC and code density similar to CISC, no need to keep a bloated instruction decoder on the CPU..
The instruction decoder is tiny compared to the rest of the components on the chip, it also can be (partially) autogenerated. I still don't want to be on the team doing that...
n-bit system has always been a bit of a vague term --- think of all the CPUs out there described as "8-bit" --- the 8080/8085/Z80 family, 6502, 8051, etc. None of them have an 8-bit address space, since otherwise they would only be able to address 256 bytes.
Even defining the address space is not trivial, with things like virtual vs. physical ("32-bit" x86 since the Pentium Pro actually has 36-bit physical addresses) and bankswitching (common on MCUs).
Likewise, data width is equally as complex: the Z80, commonly known as 8-bit, actually has operations on 16-bit "register pairs". 32-bit x86 with MMX has 64-bit registers, and with x87 has 80-bit wide quantities manipulable in a single instruction.
It just so happens that we hit a sweet spot for many years with "32-bit" x86 which had 32-bit integers and pointers, but the subtleties of classifying a system as being n-bit remain.
That said, some systems (mostly mainframes/supercomputers) are "true 64/64-bit" with 64-bit registers and 64-bit address space.
And I believe all the major 64-bit instruction sets actually use 48-bit addresses at present, so software/compilers can use the top 16 as tag bits. (In addition to the bottom 3, assuming alignment on 8-byte boundaries).
The address space in x86-64 is specifically designed to prevent the use of unused address bits for tag bits.
"The AMD specification requires that the most significant 16 bits of any virtual address, bits 48 through 63, must be copies of bit 47 (in a manner akin to sign extension). If this requirement is not met, the processor will raise an exception."
That applies only when you are actually using such an address for an access; you are free to store anything in those upper 16 bits as long as they are masked off when it's actually used to access memory.
Decades ago I read an article that pointed out that a corollary to Moore's law is that address bits will be consumed at the rate of 1.5 address bits per year, so it is easy to predict when an architecture will run out of address bits.
> And I believe all the major 64-bit instruction sets actually use 48-bit addresses at present, so software/compilers can use the top 16 as tag bits.
Not at all a safe assumption in general; architectures evolve over time, and in addition, that address space is split such that kernel addresses have those bits set, not cleared.
Didn't mean to imply that was a good idea, just that it's possible. It looks like the top supercomputers are getting close to surpassing 64 petabytes (56 bits byte-addressed) of virtual memory space, so 16-bit tags are right out. A 48-bit byte-addressed memory space is 256 terabytes, which is getting snug for high-end servers but still 15±5 years out for consumer hardware.
(as already mentioned, ints being 64-bit does not make it any more 64-bit)
It may be just a bit of hacking in the some GCC platform configuration files (I'm guessing), and getting possibly tens to hundreds of packages to work with that change (not all software is written completely portably!).
However there is no good reason to do that. It would literally make things use more memory and slower (as a consequence of the former). Any program that actually needs 64-bit integers just uses int64_t etc..
