Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #395845 > unrolled thread

8 bit cpu

Back to article view | Back to comp.lang.c

Contents

  8 bit cpu Rosario19 <Ros@invalid.invalid> - 2025-12-18 19:20 +0100
    Re: 8 bit cpu Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-18 20:03 +0000
      Re: 8 bit cpu Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-18 20:49 +0000
    Re: 8 bit cpu BGB <cr88192@gmail.com> - 2025-12-18 16:30 -0600
      Re: 8 bit cpu Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-18 15:36 -0800
        Re: 8 bit cpu Richard Heathfield <rjh@cpax.org.uk> - 2025-12-19 01:12 +0000
        Re: 8 bit cpu Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-20 19:23 +0000
          Re: 8 bit cpu Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-20 17:55 -0800
            Re: 8 bit cpu David Brown <david.brown@hesbynett.no> - 2025-12-21 13:12 +0100
              Re: 8 bit cpu Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-21 16:14 -0800
                Re: 8 bit cpu David Brown <david.brown@hesbynett.no> - 2025-12-22 08:41 +0100
      Re: 8 bit cpu David Brown <david.brown@hesbynett.no> - 2025-12-19 09:49 +0100
      Re: 8 bit cpu Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-20 22:24 +0000
    Re: 8 bit cpu David Brown <david.brown@hesbynett.no> - 2025-12-19 09:19 +0100
      Re: 8 bit cpu bart <bc@freeuk.com> - 2025-12-19 13:43 +0000
        Re: 8 bit cpu David Brown <david.brown@hesbynett.no> - 2025-12-19 16:16 +0100
          Re: 8 bit cpu bart <bc@freeuk.com> - 2025-12-19 16:05 +0000
            Re: 8 bit cpu David Brown <david.brown@hesbynett.no> - 2025-12-19 18:57 +0100
              Re: 8 bit cpu bart <bc@freeuk.com> - 2025-12-20 16:19 +0000
                Re: 8 bit cpu David Brown <david.brown@hesbynett.no> - 2025-12-20 18:29 +0100
    Re: 8 bit cpu Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-20 19:16 +0000
    Re: 8 bit cpu kalevi@kolttonen.fi (Kalevi Kolttonen) - 2025-12-24 01:11 +0000
      Re: 8 bit cpu Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-23 19:35 -0800
        Re: 8 bit cpu BGB <cr88192@gmail.com> - 2025-12-24 03:19 -0600

Page 1 of 2  [1] 2  Next page →

#395845 — 8 bit cpu

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 

[toc] | [next] | [standalone]

#395846

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.

[toc] | [prev] | [next] | [standalone]

#395847

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.

[toc] | [prev] | [next] | [standalone]

#395848

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).

...

[toc] | [prev] | [next] | [standalone]

#395849

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 */

[toc] | [prev] | [next] | [standalone]

#395850

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

[toc] | [prev] | [next] | [standalone]

#395864

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

[toc] | [prev] | [next] | [standalone]

#395868

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 */

[toc] | [prev] | [next] | [standalone]

#395872

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.

[toc] | [prev] | [next] | [standalone]

#395873

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 */

[toc] | [prev] | [next] | [standalone]

#395878

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...)

[toc] | [prev] | [next] | [standalone]

#395852

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.

[toc] | [prev] | [next] | [standalone]

#395866

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*) ...

[toc] | [prev] | [next] | [standalone]

#395851

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.

[toc] | [prev] | [next] | [standalone]

#395856

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.

[toc] | [prev] | [next] | [standalone]

#395857

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.

[toc] | [prev] | [next] | [standalone]

#395858

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.

[toc] | [prev] | [next] | [standalone]

#395859

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.

[toc] | [prev] | [next] | [standalone]

#395861

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!

[toc] | [prev] | [next] | [standalone]

#395862

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web