muta...@gmail.com  wrote:   
   > On Monday, November 28, 2022 at 11:59:14 PM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
   >   
   > > > 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.   
   >   
   > The instruction set has no such limit. You can write   
   > a program and it can run on an AM32 or even an   
   > AM64 or AM-infinity machine (as well as AM24).   
      
   Well, instruction set is defined is specific way.  You can   
   try to reinterpret it in different way, but in the process   
   you have to throw away a few intructions that do not fit.   
   And you miss several useful intructions, some added in later   
   editions, some which appear in other architectures.   
      
   > > instructions. Anyway, S370XE (that is with 31-bit   
   >   
   > XA   
   >   
   > > Once you have compiler, there is really no need to insist   
   > > that architectures are very similar.   
   >   
   > The reason I insist that is so that the assembler and   
   > linker don't need to be rewritten.   
      
   Assemblers are really not complicated.  Main part is   
   (possibly largish) table describing instructions and   
   their formats.  There rest is normally quite similar   
   unless machine has some special quirks like segmentation   
   or similar.   
      
   Normal linker really does not care about architecture.  Output   
   from compilers has slots with associated formulas (relocations).   
   What matter is what kind of relocations are needed.  And   
   once you handle S370 you basically met most difficulties   
   that can appear anywhere: fields of varying size and need   
   to put address constants in memory.  Again, if machine   
   has some quirks, then you may need special code in the   
   linker.   
      
   And actually, OS and its object formats have more impact on   
   linker than architecure.  In virtual memory OS without   
   shared libraries you can link any program to use fixed   
   addresses.  If you want to load programs at different   
   virtual adress (like in DOS), you need to apply relocations   
   during loading which make things more complicated.  Shared   
   libraries lead to extra problems.  Modern Linux uses   
   ELF format for shared libraries.  IIUC essentially the   
   same thing was done by TSS/67 folks.  But they run   
   into troubles.  AFAICS one problem was that IBM360 required   
   more more relocations than modern machines.  Another was   
   that TSS/67 was rather big for its time and took large   
   part of machine resources to itself.  In effect, smaller   
   part of machine was available to user programs leading   
   to lower efficiency than competition.   
      
   > Ritchie created a language that, as far as I can tell, was   
   > designed to last for eternity.   
      
   Well, most (all???) high level languages were designed to   
   last for eternity.  Certainly this was case with Fortran   
   and Cobol.  But as we learn more about programming we   
   want more features from programming languages.  In particular,   
   Fortran, Cobol, C when designed were viewed as high level   
   languages.  In modern times they are viewed as just one   
   step above assembly with other languages like Python   
   viewed as really high level ones.   
      
   One research OS was originally written in Haskel, proven   
   correct and then hand translated to C again with proof   
   that translation is doing the same thing as original.   
   The main point of this excercise was to get mathematical   
   proof of correctness of OS.  But as a byproduct it   
   indicates that Haskel is viable language to write an OS.   
   More precisely, authors have written OS using Haskel constructs   
   that could be translated to efficient machine code.  When   
   compiled by normal Haskel compiler OS run rather slowly,   
   so they translated it to C.  But AFAICS translation could   
   be done in mechanical way, so special purpose Haskel   
   compiler in pinciple could generate fast machine code.   
      
   > I want to write an eternal OS and eternal toolchain in that eternal language.   
   >   
   > At a minimum I want to support flat 32, 64, 128, 256-bit   
   > registers.   
   >   
   > Ideally I would support 16:16, 32:32, 64:64, 128:128   
   > segmentation too.   
   >   
   > But I don't know which architecture to settle on.   
   >   
   > I guess I could provide multiple assemblers to give   
   > more eternal OS/toolchains.   
   >   
   > BFN. Paul.   
      
   --   
                                 Waldek Hebisch   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)