muta...@gmail.com  wrote:   
   > On Sunday, November 27, 2022 at 7:23:21 AM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
   >   
   > > Concerning 370: since data may be bigger also offsets   
   > > may be bigger. It may happen that offset which in   
   > > 32-bit mode fits ino 12 bits will grow so that it no   
   > > longer fits int 12-bits. That will force you to do   
   > > some workarounds. Easiest one is to use newer   
   > > instructions with bigger offsets (this could be done   
   > > by assembler). But whatever you decide compiler must   
   > > know which offsets can be done by single instruction   
   > > and which need extra code to work around machine   
   > > limitation.   
   >   
   > Yes, the page table things will need to be more frequent   
   > as the bit size increases.   
   >   
   > > All this logic could be put in single compiler, you   
   > > just need a few parameters describing modes of your   
   > > machine. And something like command line argument   
   > > telling compiler what it should do: 32-bit mode or   
   > > 64-bit mode. As long as you do not care about quality   
   > > of generated code this could be done in very simple   
   > > compiler.   
   >   
   > Yeah, that's what I'm after.   
   >   
   > A parameter given to the compiler specifying the size.   
   > No change to the assembler required - just get it to   
   > generate the same opcodes, but now they have a   
   > 64-bit meaning instead of 32-bit. 80386 already has   
   > this notion with the x'66' and x'67' if you want the   
   > old style. Maybe something like that could be added   
   > to S/370 as an alternative 64-bit move.   
   >   
   > (note that I haven't moved to 64-bit yet anywhere that   
   > I code)   
   >   
   > Standardize on S/370. Standardize on a.out. Standardize   
   > on C90.   
      
   Well, S/370 is not good choice, it is limited to 24-bit   
   addressing.  You probably think that 360 was first   
   "nice" architecture on the market.  But original 360   
   was supposed to run with 4k of memory (I am not sure if   
   any was actually shipped with such small memory) and that   
   probably motivated some unfortunate "savings" like packing   
   extra info in top 8-bits in system registers and some   
   instructions.  Anyway, S370XE (that is with 31-bit   
   addressing) is probably minimal reasonable thing for   
   long time use.  But it appeared only 1978 and at that   
   time it was possible to do better architecture.  ARM   
   is nicer and simpler to implement.   
      
   > And you have a viable machine no matter how many bits   
   > they end up with in the future.   
   >   
   > People can still spend effort optimizing various things,   
   > writing in assembler for specific machines, using RISC,   
   > changing their mind back and forth.   
   >   
   > But the S/370 (now with 9999999 bits and counting) is   
   > always there for you.   
   >   
   > And then maybe throw in a segmented version of S/370,   
   > and make it 16-bit and 8-bit.   
      
   There was 16-bit 360: 360/20, it was limited to 64k of core   
   (or maybe only 32k).  Once you have more memory there   
   is really no sense to use 16-bit: on small machines 360/370   
   instructions were interpreted by real processor and interpreter   
   for 32-bit instructions is only marginally more complex   
   than interpreter for 16-bit instructions.  And interpreted   
   32-bit instructions are faster than segmented 16-bit ones.   
   To be more precise: both 360/20 and 360/30 stored official   
   360 registers in core memory.  Processing only 16 bits   
   could give some saving due to smaller number of accesses to   
   core.  But once you have segments in the mix there is no   
   saving: you need to handle 32-bits anyway and interpreter   
   gets more complex and slower.   
      
   > Or maybe 8086 is better suited for segmentation, so let   
   > S/370 inspire 8086 to be 999999 bit with just a compiler   
   > option.   
      
   Once you have compiler, there is really no need to insist   
   that architectures are very similar.  I can do:   
      
   ../../../../usr/bin/sdcc -mstm8 --opt-code-size -c -V pff.c   
      
   and it compiles FAT filesystem for STM8 (8-bit CISC).  Or   
      
   /mnt/m1/pom/usr/bin/avr-gcc -Os -mmcu=atmega328 -c pff.c   
      
   to compile for Atmega328 (8-bit RISC). Or   
      
   /mnt/m1/pom/usr/bin/msp430-elf-gcc -Os -c pff.c   
      
   to compile for MSP430 (16-bit RISC).  Or   
      
   /mnt/m1/pom/usr/bin/arm-none-eabi-gcc -Os -mthumb -mcpu=cortex-m0 -c pff.c   
      
   to compile for Cortex-M0 (very simplified version of ARM).  Or   
      
   /mnt/m1/pom/usr/bin/arm-none-eabi-gcc -Os -mthumb -mcpu=cortex-m3 -c pff.c   
      
   to compile for Cortex-M3 (simpilfied ARM, but much richer than M0).  Or   
   for several others.  Of course, gcc is complex compiler but this   
   complexity is mainly to get good speed and small size of object code.   
   If you are satisfied with slower and bigger code, then much simpler   
   compiler is enough.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)