From: cr88192@gmail.com   
      
   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):   
   >   
      
      
      
   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).   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)