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 2 of 2 — ← Prev page 1 [2]

#395863

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

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

#395923

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

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

#395925

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

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

#395936

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

...

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web