Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c    |    Meh, in C you gotta define EVERYTHING    |    243,242 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 242,482 of 243,242    |
|    BGB to All    |
|    Re: 8 bit cpu    |
|    18 Dec 25 16:30:46    |
   
   From: cr88192@gmail.com   
      
   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).   
      
   ...   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca