From Newsgroup: comp.lang.c

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 18 Dec 2025 19:20:09 +0100, Rosario19 wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

Leor Zolman sometimes hangs out around here; you could ask him about
BDS C for the 8bit Intel 8080.

Alternatively, you could just check out BDS C at https://www.bdsoft.com/resources/bdsc.html.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 18 Dec 2025 20:03:56 +0000, Lew Pitcher wrote:

On Thu, 18 Dec 2025 19:20:09 +0100, Rosario19 wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

Leor Zolman sometimes hangs out around here; you could ask him about
BDS C for the 8bit Intel 8080.

Alternatively, you could just check out BDS C at https://www.bdsoft.com/resources/bdsc.html.

For that matter, you could even check out the original
Small C: Ron Cain's "Small C Compiler for the 8080s" https://archive.org/details/dr_dobbs_journal_vol_05_201803/page/n189/mode/2up --
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/18/2025 12:20 PM, Rosario19 wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

There are no "true" 8 bit systems in this sense, as pretty much every
existing 8-bit CPU has had support for 16-bit operations in some way,
though often by using register pairs.

So, in this sense, it makes more sense to call them 8/16 instead, as the
exact line between 8-bit machines and 16-bit machines is often a little
fuzzy (and both tend to look basically similar as far as C is concerned;
for the machines big enough to where running C on them is viable).



One could then ask, what would a minimal 8-bitter look like.
Might make sense to go with fixed-length 16-bit instructions.
Likely 8x8b registers;
...

Say:
AL, AH
BL, BH
CL, CH
SP, LR

If you want a 16-bit ADD, you do two:
ADD, ADC

Then, say:
RCL/RCR (Rotate Carry Left/Right, 1-bit)
CLC, STC (Clear/Set Carry)
CMPLTZ (Compare Less Than Zero, Set/Clear Carry)
Essentially "Copy sign bit to Carry".
CMPEQZ (Set Carry if Src==0)
BT/BF/BRA/BSR (Disp8)
JMP reg ("RTS"=="JMP LR")
LI (2RI, Copy 8-bit value to register)
LB/SB (Load/Store Byte)
MOV, AND, OR, XOR (2R)
ADD / ADC, SUB / SBB
...

Could probably implement most of C in this. Lots of stuff is going to
need to be implemented as runtime functions though.
SUB/SBB, not strictly necessary but would save a lot of instructions.


For extra fun, could maybe try to use an 8-bit address space, but more
likely just 16-bit with register pairs, say:
AX, BX, CX, SP
Except LB/SB Src/Dst: AX, BX, CX, LR
With addressing modes, say:
[SP+AX] / [BX+AX] / [BX] / [CX]
[BX+Disp2*2+Rd[0]] //4x 16-bit words
[SP+Disp3*2+Rd[0]] //8x 16-bit words
Allows fitting every possibility into 4 bits.


So, for example, if you do:
if(x>y) { ... }
LW AX, [SP+2]
LW CX, [SP+4]
SUB CX, AX
CMPLTZ CX
BF .L0
...
These being mostly pseudo-instructions that crack into byte ops.

Could maybe go "more minimal", but then the number of instructions
needed to do "pretty much anything" would get a bit absurd (would be
less useful to have an 8-bitter where pretty much no useful program
could fit into a reasonable-sized ROM space).

Then again, maybe someone could come up with something both less bad and
more minimal (well, for those who feel things like the 6502 were maybe a little too feature-rich).

...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

BGB <cr88192@gmail.com> writes:
[...]

There are no "true" 8 bit systems in this sense, as pretty much every existing 8-bit CPU has had support for 16-bit operations in some way,
though often by using register pairs.

I vaguely recall reading about a true 8-bit system, maybe from the 1950s
or so.

It had a total of 8 bits of storage.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/12/2025 23:36, Keith Thompson wrote:

BGB <cr88192@gmail.com> writes:
[...]

There are no "true" 8 bit systems in this sense, as pretty much every
existing 8-bit CPU has had support for 16-bit operations in some way,
though often by using register pairs.

I vaguely recall reading about a true 8-bit system, maybe from the 1950s
or so.

It had a total of 8 bits of storage.

I wrote a computer that was wholly octet-based - *Everything* was
8-bit. 256 bytes of RAM, 256 bytes in a separate stack, and 256
8-bit registers. No support for any wider type. It's a few
hundred lines of C, nothing difficult. So 'There are no "true" 8
bit systems' might or might not be true of hardware, but it's not
true of software.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/12/2025 19:20, Rosario19 wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

No, 8-bit cpus don't need 16-bit registers or 16-bit operations. 8-bit
cpus typically only have 8-bit general registers (though most will have
a 16-bit PC register). Some will allow you to use a couple of 8-bit
registers in a pair, primarily for memory addressing, but a pair of
8-bit registers is not the same as a 16-bit register.

And of course some 8-bit cpus don't have direct access to more than 256
memory locations - support for anything more is indirect in some way
(using page registers or other arrangements).

It is fair to say, however, that most "big" 8-bit cpus have either one
or more 16-bit address registers, or a reasonable way to combine two
8-bit registers in a pair for use in addressing. And many such "big"
8-bit cpus have a few 16-bit operations, such as for loading or storing
a register pair, or incrementing or decrementing them.

And all this is simply saying that if a processor is going to be able to access more than 256 bytes of memory with reasonable efficiency, it has
to be able to handle pointer sizes of 16-bit without too much overhead.
It says nothing about the need for a general data size greater than
8-bit (and "int" is for general data, not pointers or addresses).

For 8-bit devices, using 16-bit data for logic, arithmetic, counters,
data movement, etc., is significantly slower than using 8-bit. That's
why they are called 8-bit devices.

C plays by different rules - it is defined on an abstract machine, not
any particular hardware. It says that the size of an "int" is implementation-defined, but it must be at least 16 bits. Thus any C implementation for 8-bit processors will have 16-bit ints - not because
it is a good size for the device (it certainly is not), but because
otherwise it would not be C. (The size of pointers is not specified by
the standard - though you can infer a minimum of at least 15-bit data
pointers for hosted systems, 12-bit data pointers for freestanding
systems, and 12-bit function pointers.)

The C requirement for a minimum size of 16-bit int, together with the
integer promotion rules, is one of the reasons C was often considered inefficient and inappropriate for small 8-bit microcontrollers. In the
heyday of 8-bit microcontrollers, many were programmed in assembly
rather than C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 18/12/2025 23:30, BGB wrote:

On 12/18/2025 12:20 PM, Rosario19 wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

There are no "true" 8 bit systems in this sense, as pretty much every existing 8-bit CPU has had support for 16-bit operations in some way,
though often by using register pairs.

That is, at best, an exaggerated interpretation.

So, in this sense, it makes more sense to call them 8/16 instead, as the exact line between 8-bit machines and 16-bit machines is often a little fuzzy (and both tend to look basically similar as far as C is concerned;
for the machines big enough to where running C on them is viable).

One could then ask, what would a minimal 8-bitter look like.
  Might make sense to go with fixed-length 16-bit instructions.
  Likely 8x8b registers;
  ...

Say:
  AL, AH
  BL, BH
  CL, CH
  SP, LR

If you want a 16-bit ADD, you do two:
  ADD, ADC

There are lots of 8-bit processors with /far/ fewer registers than that.

The 6502, had :

A = 8-bit accumulator
X = 8-bit index register
Y = 8-bit index register

S = 8-bit stack pointer
P = 8-bit flag register
PC = 16-bit program counter

Access to the zero page was fast - access to memory beyond that was done (IIRC) with a 16-bit base address stored in the zero page memory, added
to an 8-bit index register. There were no 16-bit registers, no register
pairs (though I think some 6502 variants could use an XY pair for
addressing), no 16-bit operations.

A microcontroller I used on a lot of projects was the COP8. It had one
8-bit register "A", and a 16-bit PC. Access to wider memory was via paging.


Devices with only 8-bit program counters were typically only for very
niche uses where cost was absolutely critical - there's not a lot you
can do with 256 bytes (or perhaps 256 16-bit words) of program space.
But there were plenty of 8-bit microcontrollers where the PC was not
really 16-bit, but was more of an 8-bit "PC_lo" register combined with a paging register (which might have been a fair bit smaller than 8-bit).
Code flow would wrap within a page rather than moving seamlessly on to
the next page. (Of course all such systems were Harvard architectures
with completely separate code and data.)


And at one time, 4-bit microcontrollers were the dominant architecture
in terms of the number of devices made and sold. These usually had a
way to combine two registers to get 8-bit address registers.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 19/12/2025 08:19, David Brown wrote:

On 18/12/2025 19:20, Rosario19 wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

No, 8-bit cpus don't need 16-bit registers or 16-bit operations.  8-bit cpus typically only have 8-bit general registers (though most will have
a 16-bit PC register).  Some will allow you to use a couple of 8-bit registers in a pair, primarily for memory addressing, but a pair of 8-
bit registers is not the same as a 16-bit register.

The C requirement for a minimum size of 16-bit int, together with the integer promotion rules, is one of the reasons C was often considered inefficient and inappropriate for small 8-bit microcontrollers.

I'm targeting Z80 right now from my systems language.

As well as making 'int' 16 bits, I've removed the promotion rules. This
means 8-bit quantities needing to be cast to 16 bits as needed.

So if 'a b c' are 8 bits, and 'x' is 16 bits then the Clang Z80 compiler generates 8-bit code only for:

a = b + c;

No promotions. But here:

x = b + c;

'b' and 'c' are first widened to 16 bits (using some ugly code when they
are signed).

This is where my language will differ: b + c produces an 8-bit result,
and it is that that is widened.

Casts are needed to emulate the behaviour of the auto-widening done in
C. But this means somewhat more efficient code with a simpler compiler.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 19/12/2025 14:43, bart wrote:

On 19/12/2025 08:19, David Brown wrote:

On 18/12/2025 19:20, Rosario19 wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

No, 8-bit cpus don't need 16-bit registers or 16-bit operations.
8-bit cpus typically only have 8-bit general registers (though most
will have a 16-bit PC register).  Some will allow you to use a couple
of 8-bit registers in a pair, primarily for memory addressing, but a
pair of 8- bit registers is not the same as a 16-bit register.

The C requirement for a minimum size of 16-bit int, together with the
integer promotion rules, is one of the reasons C was often considered
inefficient and inappropriate for small 8-bit microcontrollers.

I'm targeting Z80 right now from my systems language.

The Z80 is actually one of those 8-bit cpus that could be called an
8/16-bit device - it has a lot of support for using register pairs BC,
DE, and HL as 16-bit registers, and IX and IY are already 16-bit.
(Ironically, the early versions used a 4-bit ALU with double-pumping.)

As well as making 'int' 16 bits, I've removed the promotion rules. This means 8-bit quantities needing to be cast to 16 bits as needed.

So if 'a b c' are 8 bits, and 'x' is 16 bits then the Clang Z80 compiler generates 8-bit code only for:

    a = b + c;

No promotions.

Technically, there /are/ promotions there - C requires them. But C
compilers optimise with the "as-if" rules, and with the normal choices
of implementation-defined integer conversions the result of this kind of operation is always going to be identical to a C-like language without promotions. (Or C with _BitInt(8) types for a, b, and c.)

In some C compilers for 8-bit devices, this kind of optimisation is done fairly early in the pipeline, so that the addition here is interpreted
as though it were an unpromoted 8-bit operation. In others, such as
avr-gcc, many such operations are given normal integer promotions and
then redundant operations and register moves are removed with peephole optimisations at code generation. That second approach makes the implementation much easier as you don't need special handling at the
front-end or in the middle of the compiler, but it has the disadvantage
of being less efficient for register allocation and having occasional
extra instructions when the peepholes are not perfect.

But here:

    x = b + c;

'b' and 'c' are first widened to 16 bits (using some ugly code when they
are signed).

Of course. (8-bit devices are usually designed for primarily unsigned
data, and often don't have neat ways of handling or extending signed types.)

This is where my language will differ: b + c produces an 8-bit result,
and it is that that is widened.

Okay. I think that is a better choice for a language for 8-bit devices
than the choice C made. I understand the rules for C integer promotion,
but I don't like them.

Casts are needed to emulate the behaviour of the auto-widening done in
C. But this means somewhat more efficient code with a simpler compiler.

Yes.

Why are you targeting the Z80? Is it just for fun? It was a great
device in its time, and I learned a lot of assembly with that processor,
but has been decades since it was used for anything new. While the
chips are still available, they are for legacy use - no one will be
writing new code for them, merely maintaining old code.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 19/12/2025 15:16, David Brown wrote:

On 19/12/2025 14:43, bart wrote:

I'm targeting Z80 right now from my systems language.

This is where my language will differ: b + c produces an 8-bit result,
and it is that that is widened.

Okay.  I think that is a better choice for a language for 8-bit devices than the choice C made.  I understand the rules for C integer promotion, but I don't like them.

I think it is a better choice for a capable processor, and I actually
adopted C's approach at some point.

Currently it works very well for my 64-bit product, but here C stops
short at promoting only to 32 bits! (When 'int' is 32 bits.) So you have
a mix of auto-promotion plus explicit casts to 64 bits.

Casts are needed to emulate the behaviour of the auto-widening done in
C. But this means somewhat more efficient code with a simpler compiler.

Yes.

Why are you targeting the Z80?  Is it just for fun?

Mostly, yes. My Z80 will be emulated, and I hadn't worked on an emulator before.

Currently, emulated Z80 code runs at an equivalent clock-speed of 2-4GHz
(for whole-instruction-based emulation; some emulate clock-by-clock and
do pin-signals too).

The original Z80s ranged from 2.5 to 8MHz. (Newer Z80-based CPUs take
fewer clocks per instruction, and may use pipelining.)

The other side of it is in exercising the IL I use for my compilers, and seeing how well it can cope with a small device. My product will be a cross-compiler, and it'll be a novelty seeing modern language features
(lots don't depend on target capabilities) be used for such a device.

(I wrote real Z80 compilers in the past; those actually ran on the Z80!
But were crude.)

  It was a great
device in its time, and I learned a lot of assembly with that processor,
but has been decades since it was used for anything new.  While the
chips are still available,

They stopped making Z80 chips in 2024 (you can still get Z180 etc). I've
got one on my shelf somewhere (decades ago my company bought them in
bulk!). I might get around to using it for real.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 19/12/2025 17:05, bart wrote:

On 19/12/2025 15:16, David Brown wrote:

On 19/12/2025 14:43, bart wrote:

I'm targeting Z80 right now from my systems language.

This is where my language will differ: b + c produces an 8-bit
result, and it is that that is widened.

Okay.  I think that is a better choice for a language for 8-bit
devices than the choice C made.  I understand the rules for C integer
promotion, but I don't like them.

I think it is a better choice for a capable processor, and I actually adopted C's approach at some point.

Currently it works very well for my 64-bit product, but here C stops
short at promoting only to 32 bits! (When 'int' is 32 bits.) So you have
a mix of auto-promotion plus explicit casts to 64 bits.

I think making "int" 64-bit would have been a bad choice overall for C.

The key issue is that there is a conflict of uses and efficiency on
64-bit processors between "a type that is fast and convenient for local
use" and "a type that is big enough to handle most numbers, and fast and efficient for storage". Data in memory, especially in arrays, is more efficient if it is smaller - 32-bit is still a good size for the
majority of numbers stored in memory. For local variables in registers,
or even on the stack, 64-bit is more efficient on x86-64 as it avoids
the need of any kind of sign or zero extension or masking.

So ideally in C programming, you'd use "int_least32_t" for integers in
memory (unless you know they are small values in a big array, and pick something smaller), while you'd use "int_fast32_t" (64-bit on x86-64)
for integers in local variables in functions. But of course no one does
that for normal code - they use "int". 32-bit "int" is therefore good
in some ways and less than ideal in others. However, given that such a
large proportion of code was written with the assumption that "int"
always means 32-bit, it made sense to keep it at 32-bit.


There are various ways of handling integer promotion rules - you can
have no promotion, use C-style promote-to-int, promote to the natural
width of the target, or promote based on what is being done with the
result. Each method has its pros and cons. The most important thing is
that the rules should be clear enough that programmers know what they
are getting, and that there are reasonable ways to modify the behaviour
as needed.

(There are other methods that can be used that involve more changes to
the structure of the language - Forth, for example, uses different
operators for word-sized operations and double-word operations.)

Casts are needed to emulate the behaviour of the auto-widening done
in C. But this means somewhat more efficient code with a simpler
compiler.

Yes.

Why are you targeting the Z80?  Is it just for fun?

Mostly, yes. My Z80 will be emulated, and I hadn't worked on an emulator before.

Fair enough. That's always a good reason. Nostalgia works too :-)

Currently, emulated Z80 code runs at an equivalent clock-speed of 2-4GHz (for whole-instruction-based emulation; some emulate clock-by-clock and
do pin-signals too).

The original Z80s ranged from 2.5 to 8MHz. (Newer Z80-based CPUs take
fewer clocks per instruction, and may use pipelining.)

The other side of it is in exercising the IL I use for my compilers, and seeing how well it can cope with a small device. My product will be a cross-compiler, and it'll be a novelty seeing modern language features
(lots don't depend on target capabilities) be used for such a device.

(I wrote real Z80 compilers in the past; those actually ran on the Z80!
But were crude.)

  It was a great device in its time, and I learned a lot of assembly
with that processor, but has been decades since it was used for
anything new.  While the chips are still available,

They stopped making Z80 chips in 2024 (you can still get Z180 etc). I've
got one on my shelf somewhere (decades ago my company bought them in
bulk!). I might get around to using it for real.

I have a ZX Spectrum in the loft somewhere, but I don't know if it is
still working. It has the keyboard from a dead TI 99/4A transplanted in
place of the broken chewing gum original.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 19/12/2025 17:57, David Brown wrote:

On 19/12/2025 17:05, bart wrote:

[Default size 'int' being 32 or 64 bits]

Currently it works very well for my 64-bit product, but here C stops
short at promoting only to 32 bits! (When 'int' is 32 bits.) So you
have a mix of auto-promotion plus explicit casts to 64 bits.

I think making "int" 64-bit would have been a bad choice overall for C.

The key issue is that there is a conflict of uses and efficiency on 64-
bit processors between "a type that is fast and convenient for local
use" and "a type that is big enough to handle most numbers, and fast and efficient for storage".  Data in memory, especially in arrays, is more efficient if it is smaller

Sure. Then you choose the smallest size that can represent all likely
values.

But if you don't know the range of values, would you just use 'int' and
hope nothing is outside the i32 range? Or would you use 64 bits?

If the latter, then a default i64 size (with a range /4 billion times
wider/ than i32) can make more sense.

- 32-bit is still a good size for the
majority of numbers stored in memory.  For local variables in registers,
or even on the stack, 64-bit is more efficient on x86-64 as it avoids
the need of any kind of sign or zero extension or masking.

One mild downside on x64 is the need for a 'REX' prefix on some
instructions that work on 64-bits (to set the 'W' bit). Unless the instructions already use x64's 8 extra registers so the prefix is needed anyway.

However, given that such a
large proportion of code was written with the assumption that "int"
always means 32-bit, it made sense to keep it at 32-bit.

Could the same assumptions have been made about 'long'? I guess was
'long' was 32 bits when 'int' was 16 bits, then when the latter became
32 bits, 'long' stayed the same...

...until 64 bit machines came along. Then 'int' stayed the same, but
'long' became 64 bits - on some OSes but not others!

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 20/12/2025 17:19, bart wrote:

On 19/12/2025 17:57, David Brown wrote:

On 19/12/2025 17:05, bart wrote:

[Default size 'int' being 32 or 64 bits]

Currently it works very well for my 64-bit product, but here C stops
short at promoting only to 32 bits! (When 'int' is 32 bits.) So you
have a mix of auto-promotion plus explicit casts to 64 bits.

I think making "int" 64-bit would have been a bad choice overall for C.

The key issue is that there is a conflict of uses and efficiency on
64- bit processors between "a type that is fast and convenient for
local use" and "a type that is big enough to handle most numbers, and
fast and efficient for storage".  Data in memory, especially in
arrays, is more efficient if it is smaller

Sure. Then you choose the smallest size that can represent all likely values.

But if you don't know the range of values, would you just use 'int' and
hope nothing is outside the i32 range? Or would you use 64 bits?

For me personally, I /do/ know the range of values when I write code,
and thus pick appropriate sizes. But in general, 32-bit really is
enough for almost all cases. It is extraordinarily rare that code will
come across a number that does not fit inside a 32-bit int, without the programmer being fully aware of the situation. (The exception is if the programmer is doing some weird 1990's style uncontrolled conversions
between pointers/addresses and integer types.)

If the latter, then a default i64 size (with a range /4 billion times
wider/ than i32) can make more sense.

- 32-bit is still a good size for the majority of numbers stored in
memory.  For local variables in registers, or even on the stack, 64-
bit is more efficient on x86-64 as it avoids the need of any kind of
sign or zero extension or masking.

One mild downside on x64 is the need for a 'REX' prefix on some
instructions that work on 64-bits (to set the 'W' bit). Unless the instructions already use x64's 8 extra registers so the prefix is needed anyway.

You know the messy details of x86 machine code far better than I do.

However, given that such a large proportion of code was written with
the assumption that "int" always means 32-bit, it made sense to keep
it at 32-bit.

Could the same assumptions have been made about 'long'? I guess was
'long' was 32 bits when 'int' was 16 bits, then when the latter became
32 bits, 'long' stayed the same...

...until 64 bit machines came along. Then 'int' stayed the same, but
'long' became 64 bits - on some OSes but not others!

"long" was made 64-bit on all sane 64-bit platforms (remember that x86
was late to that party), because at that time C had no other standard
way to describe a 64-bit type. And even once C99 came along and "long
long" was standardised as being at least 64 bits, I'm sure you will
agree that "long long int" is not the nicest or clearest of type names!
When the decision was made to keep "int" at 32-bit on platforms that
moved to 64 bits (a decision that I think was correct overall, but not
without its disadvantages), making "long" 64-bit was definitely the
right move.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-12-18, Rosario19 <Ros@invalid.invalid> wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

To access more memory locations than 0 to 255 using a single binary
address, we only need 9 bits. 16 is not the lower bound on how many
bits we need.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2025-12-18, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

BGB <cr88192@gmail.com> writes:
[...]

There are no "true" 8 bit systems in this sense, as pretty much every
existing 8-bit CPU has had support for 16-bit operations in some way,
though often by using register pairs.

I vaguely recall reading about a true 8-bit system, maybe from the 1950s
or so.

Any guitar pedal with an electronic bypass toggle is a 1 bit system.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On Thu, 18 Dec 2025 16:30:46 -0600, BGB wrote:

There are no "true" 8 bit systems in this sense, as pretty much every existing 8-bit CPU has had support for 16-bit operations in some way,
though often by using register pairs.

But some were more 8-bit than others ... (*cough* 6502 *cough*) ...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Kaz Kylheku <046-301-5902@kylheku.com> writes:

On 2025-12-18, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

BGB <cr88192@gmail.com> writes:
[...]

There are no "true" 8 bit systems in this sense, as pretty much every
existing 8-bit CPU has had support for 16-bit operations in some way,
though often by using register pairs.

I vaguely recall reading about a true 8-bit system, maybe from the 1950s
or so.

Any guitar pedal with an electronic bypass toggle is a 1 bit system.

But not a 1-bit computer.

The system I referred to above was an actual computer with 8 bits of
storage.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 21/12/2025 02:55, Keith Thompson wrote:

Kaz Kylheku <046-301-5902@kylheku.com> writes:

On 2025-12-18, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

BGB <cr88192@gmail.com> writes:
[...]

There are no "true" 8 bit systems in this sense, as pretty much every
existing 8-bit CPU has had support for 16-bit operations in some way,
though often by using register pairs.

I vaguely recall reading about a true 8-bit system, maybe from the 1950s >>> or so.

Any guitar pedal with an electronic bypass toggle is a 1 bit system.

But not a 1-bit computer.

The system I referred to above was an actual computer with 8 bits of
storage.

Do you really mean a total of 8 bits of storage, or do you mean storage addressable by 8 bits (thus avoiding the need for any 16-bit registers
or other registers bigger than 8 bits) ?

With only 8 bits of storage, you are basically talking about a simple programmable state machine or programmable logic, not a programmable
computer. (There are programmable logic devices available with such
small numbers of storage bits - the GreenPAK family is perhaps the best example.)

The smallest device I programmed in C had no ram at all, but it had 32
8-bit registers, a three-entry return stack, 32 bytes of eeprom (IIRC),
and I think 1k x 16-bit flash for the program.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown <david.brown@hesbynett.no> writes:

On 21/12/2025 02:55, Keith Thompson wrote:

Kaz Kylheku <046-301-5902@kylheku.com> writes:

On 2025-12-18, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

BGB <cr88192@gmail.com> writes:
[...]

There are no "true" 8 bit systems in this sense, as pretty much every >>>>> existing 8-bit CPU has had support for 16-bit operations in some way, >>>>> though often by using register pairs.

I vaguely recall reading about a true 8-bit system, maybe from the 1950s >>>> or so.

Any guitar pedal with an electronic bypass toggle is a 1 bit system.

But not a 1-bit computer.

The system I referred to above was an actual computer with 8 bits of
storage.

Do you really mean a total of 8 bits of storage, or do you mean
storage addressable by 8 bits (thus avoiding the need for any 16-bit registers or other registers bigger than 8 bits) ?

As I wrote in the original followup, in context that was later
snipped, "It had a total of 8 bits of storage."

I think it used vacuum tubes.

I can't find a reference. As you can imagine, web searches for
"8-bit computer" are not productive.

There could be any number of reasons why it wouldn't qualify as a
programmable computer. I don't remember, or never knew, the details.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 22/12/2025 01:14, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 21/12/2025 02:55, Keith Thompson wrote:

Kaz Kylheku <046-301-5902@kylheku.com> writes:

On 2025-12-18, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

BGB <cr88192@gmail.com> writes:
[...]

There are no "true" 8 bit systems in this sense, as pretty much every >>>>>> existing 8-bit CPU has had support for 16-bit operations in some way, >>>>>> though often by using register pairs.

I vaguely recall reading about a true 8-bit system, maybe from the 1950s >>>>> or so.

Any guitar pedal with an electronic bypass toggle is a 1 bit system.

But not a 1-bit computer.

The system I referred to above was an actual computer with 8 bits of
storage.

Do you really mean a total of 8 bits of storage, or do you mean
storage addressable by 8 bits (thus avoiding the need for any 16-bit
registers or other registers bigger than 8 bits) ?

As I wrote in the original followup, in context that was later
snipped, "It had a total of 8 bits of storage."

I think it used vacuum tubes.

I can't find a reference. As you can imagine, web searches for
"8-bit computer" are not productive.

There could be any number of reasons why it wouldn't qualify as a programmable computer. I don't remember, or never knew, the details.

Fair enough.

Certainly "things", though not "computers" as such, were made with such
small numbers of bits. It would surprise me a little if they were ever
made using vacuum tubes. Relays were much cheaper and easier to work
with - vacuum tubes were used in early computers for speed, and because
they tolerated a lot higher switch count than relays. But for anything
were 8 bits was sufficient, it is likely that you don't need such speed
- even with early relays you could exhaust your entire state space in a
few seconds.

It is also possible that what you had heard about was only part of a
cpu, such as the ALU (although I don't know how much of a distinction
was made of the parts of a processor in those days).

Still, you have piqued my curiosity here, so if you come across this
again, I'd enjoy hearing more about it. (Though I suspect there will
never be a C compiler for the machine...)


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Rosario19 <Ros@invalid.invalid> wrote:

8 bit cpu for access memory other than 0..255 location has need at
last one 16 bit register and 16 bits operations, so i think that even
a 8 bit cpu has to have int in C language as 16 bits

I do not know whether C standards permit 8-bit ints, but
cc65 is a real-world 6502 C cross-compiler available straight
from the standard repositories on Fedora Linux 43 and FreeBSD 15.

We can install cc65 and VICE emulator to do a simple test:

$ cat foo.c
#include <stdio.h>

int main(void)
{
printf("%d\n", sizeof(int));
printf("%d\n", sizeof(void *));

return 0;
}

$ cl65 -o test.prg -t c64 foo.c

$ c1541 -format mydisk,01 d64 mydisk.d64

$ c1541 mydisk.d64
OPENCBM: opening dynamic library libopencbm.so failed!
D64 disk image recognised: mydisk.d64, 35 tracks.
Unit 8 drive 0: D64 disk image attached: mydisk.d64.
c1541 (VICE 3.9)
Copyright 1995-2024 The VICE Development Team.
C1541 is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.

c1541 #8> write test.prg test
writing file `TEST.PRG' as `TEST' to unit 8

c1541 #8> exit
Unit 8 drive 0: D64 disk image detached: mydisk.d64.

$ x64 mydisk.d64 &

VICE will load and run test.prg automatically on booting Commodore 64 emulation. We can observe the following:

--------------------------------
load"*",8,1

searching for *
loading
ready
run
2
2

ready
--------------------------------

6502, or rather 6510 on C64, hardware can do only 8-bit
machine language operations on math-capable registers, but
cc65 compiler indeed makes C language 'int' to be 16 bits just
like the pointers for memory addressing are 16 bits.

Z80, another 8-bit CPU, has machine language instructions
for doing 16-bit arithmetic by concatenating two 8-bit registers.

I do not think 6502 has such a feature in its instruction
set architecture.

br,
KK


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
[...]

I do not know whether C standards permit 8-bit ints,

It does not. C (up to C17) requires INT_MIN to be -32767 or lower,
and INT_MAX to be +32767 or higher. (C23 changes the requirement
for INT_MIN from -32767 to -32768, and mandates 2's-complement for
signed integer types.)

but
cc65 is a real-world 6502 C cross-compiler available straight
from the standard repositories on Fedora Linux 43 and FreeBSD 15.

We can install cc65 and VICE emulator to do a simple test:

[...]

I have cc65 on my Ubuntu system. Here's how I demonstrated the same
thing (that sizeof (int) is 2):

$ cat c.c
int SIZEOF_INT = sizeof (int);
$ cc65 c.c
$ cat c.s
;
; File generated by cc65 v 2.18 - Ubuntu 2.19-1
;
.fopt compiler,"cc65 v 2.18 - Ubuntu 2.19-1"
.setcpu "6502"
[7 lines deleted]
.export _SIZEOF_INT

.segment "DATA"

_SIZEOF_INT:
.word $0002

$
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/23/2025 9:35 PM, Keith Thompson wrote:

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
[...]

I do not know whether C standards permit 8-bit ints,

It does not. C (up to C17) requires INT_MIN to be -32767 or lower,
and INT_MAX to be +32767 or higher. (C23 changes the requirement
for INT_MIN from -32767 to -32768, and mandates 2's-complement for
signed integer types.)

but
cc65 is a real-world 6502 C cross-compiler available straight
from the standard repositories on Fedora Linux 43 and FreeBSD 15.

We can install cc65 and VICE emulator to do a simple test:

[...]

I have cc65 on my Ubuntu system. Here's how I demonstrated the same
thing (that sizeof (int) is 2):

<snip>

In effect pointing out part of what I had meant by there being no true
8-bit systems in the sense mentioned in the OP.

Seems like maybe people missed my point as implying that there were no
8-bit systems in general.

Like, even the most 8-bit CPUs around (such as the 6502 and similar)
still had 16-bit 'int' and pointer types in C. And, at the same time,
this is basically the minimum at which one has a system that is still
capable of usefully running C.

Well, at least in part because it wouldn't be terribly useful to try to
write C code on something that is likely to run out of address space
before you could even provide an implementation of "printf()" or similar
(*1).

But, yeah, it is annoyingly difficult for me to respond in a way that
isn't either a 1-liner or going off down a rabbit hole.



*1: Though, admittedly, I had sometimes used there sorts of tiny address spaces mostly for things like genetic programming experiments. Where,
say, one use-case is to implement something sorta like a tiny RISC
machine or similar with a simplistic ISA, and then mutate the programs
and see if by-chance they start doing anything useful or interesting.

Though, this is sort of its own topic, and also the irony that in many
of these sorts of experiments one may use 32 or 64 bits (in actual
memory) to represent each byte (it tends to work better if there is a
certain level of "nuance" and each bit is more a probability of being 1
or 0, rather than being 1 or 0 directly). Well, that and gray-coding, etc.

Well, and also things like making some parameters (such as mutation rate
and the specific strategies used for mutating bits) themselves be under
the control of the genetic algorithm.

Could potentially also "evolve" something like a C64 or NES program so
long as one has the test logic in place (an emulator) and some way to
evaluate the "goodness" of the answers (often this part is the harder part).

Well, same basic strategies also work for things like neural nets and
state machines and whatever else as well.


Works better mostly for small things, at a certain complexity level this strategy stops scaling very well (trying to use genetic algorithms to
evolve a font or a word-predicting neural nets or similar were not particularly effective).

Well, and in a few cases where I realized that using a genetic algorithm
was in-fact slower than using a brute force search (as in the font
scenario).

...

--- Synchronet 3.21a-Linux NewsLink 1.2