From: muta...@gmail.com   
      
   On Friday, August 13, 2021 at 1:17:26 AM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
      
   > > The correct thing to do, when programming on a   
   > > 1 MiB machine, is to think about a 2 MiB machine.   
   > >   
   > > The correct thing to do when programming on a   
   > > 2 MiB machine is to think about a 1 MiB machine.   
      
   > Nobody puts arbitrary restriction for no reason.   
      
   Someone put a restriction on 16-bit x86 to stop   
   at 1 MiB. There was no reason for that. Just because   
   ONE single processor SO HAPPENED to have a   
   4-bit segment shift is not a reason to tie your   
   code down.   
      
   > > Ok, my interest is in placing the 3 MB GCC executable   
   > > on unpaged memory and running it directly on the   
   > > processor. If there was some 10% overhead because   
   > > of some design decision, that would be OK.   
      
   > Hmm, you in several places rejected various possible   
   > solutions as too inefficient or too complex. So,   
   > how much inefficiency is acceptable?   
      
   10%, negotiable.   
      
   > > TSS-360 is an operating system, and there is nothing   
   > > they can do to prevent GCCMVS, which is bottlenecked   
   > > on CPU speed/memory access, not I/O, from running   
   > > at identical (or at least within 10%) speed as CP-67.   
   > > The OS simply doesn't have control of a S/360 executable   
   > > that is running.   
      
   > You forget about issues like paging, executable format,   
   > etc. gcc-3.2.3 is big enough that it will not fit   
   > into real memory of any machine on whcih TSS-360 was   
   > developed, so you would have to depend on virtual   
   > memory and paging.   
      
   No, I don't want virtual memory and paging. I will wait   
   until the hardware becomes available so that I can place   
   TSS/360 and GCC 3.2.3 into real memory. I don't care   
   about executable format so long as the 3 MiB image is   
   loaded onto real memory as expected and run at native   
   speed.   
      
   > > If TSS-360 uses more memory for the OS itself, I don't   
   > > really care. I'll just sell my car or rob a bank to pay for the   
   > > memory. I'm not willing to change my OS design from what   
   > > I think is clean. And bear in mind that I know I'm going to   
   > > have 4 GiB of RAM within my lifetime, when I need less   
   > > than 32 MiB of RAM for everything that is important to me.   
      
   > OK, so you reall do not care about old/small machines. So   
   > why make fuss about 8086 1M limit? You can cheaply get ARM   
   > board with 1G RAM, but you are unlikely to ever get   
   > money for 8086 with 512M of memory. And if you get this   
   > money, tiny fraction will be enough to hire somebody   
   > to wrote your deam editor. OK, you could cheat and   
   > use FPGA or emulator. But then we are into silly   
   > game like "how fast you can run with both you legs   
   > closely tied together".   
      
   No. None of those things are what I want. I want to   
   write an editor for the 8086, and watch my executable   
   (completely unchanged) exceed 1 MiB when the   
   80386 is released with 2 MiB of memory and   
   MSDOS-32.   
      
   And today I expect that same executable to be accessing   
   512 MiB of memory. In fact, that should have happened   
   roughly a couple of decades ago.   
      
   > I doubt that you fixed (or even noticed) problem   
   > that I mentioned. It is possible that you got   
   > version already containing the fix (I am not sure   
   > if fix is in GCC 3.2.3, it is in GCC 3.4.6).   
      
   When I picked up GCC 3.2.3, there was code that was   
   supposed to reload the base register at 4k intervals,   
   but it wasn't working.   
      
   What I did to solve the problem was unconditionally   
   load the base register once a function exceeded   
   4k, instead of the convoluted algorithm previously   
   being used to determine whether that was needed   
   or not.   
      
   > gcc was able to compile itself also before the   
   > problem I mention was fixed: gcc constains a bunch   
   > of large funtions that apparently they did not   
   > trigger the bug. More generally, testing compiler   
   > by rebuilding itself is weakest possible test.   
   > Minimal thing to do is to run compiler test suite.   
      
   No, the minimal thing to do was to just get gcc   
   to compile itself on MVS. It didn't even pass that   
   test until an awful lot of work by me and others.   
   One guy (Dave Wade) fried something like 3   
   CPUs in the process of endlessly rebuilding GCC   
   (on CMS).   
      
   > > I am only interested in the code generated by   
   > > gcc, or something better than gcc. IBM's C   
   > > compiler produces beautiful code, better than   
   > > gcc, but I'm happy to use gcc as a reference   
   > > point.   
   > >   
   > > I have no interest in PL/1.   
      
   > OK, you are thinking only about yourself. Do not you   
   > think that numerous folks who used IBM systems would   
   > appreciate better performance?   
      
   When I have C working to my satisfaction, using   
   characters on the US ASCII keyboard, in EBCDIC,   
   I'll start branching out. PL/1 is not my first priority.   
   I'm more interested in 6 ASCII control characters   
   being relinquished for use by Vietnamese.   
      
   > > The amount of code involved in access methods is   
   > > completely trivial compared to the 4 GiB of memory   
   > > I have available, and everything fits into less than   
   > > 32 MiB, and I just realized that PDOS/3X0 supports   
   > > the subset of access methods that I care about, and   
   > > PDOS/3X0 is only about 5k lines of C code total.   
      
   > If efficiency is no a concern, programming gets much   
   > simpler.   
      
   My idea of efficiency is compiled C code, in real   
   memory, running at native speed, and with all   
   its data cached, so quibbling about I/O is a   
   non-issue.   
      
   That is the nature of GCCMVS.   
      
   > Do you know that every programming problem   
   > was solved in 1957, when General Problen Solver was   
   > invented? The only trouble is that we are still   
   > waiting for machines fast enough so that is can   
   > solve some interesting problems in reasonable time.   
      
   No, I'm not familiar with that.   
      
   > > Well, if we're talking about what I want, then I also want   
   > > the OS to be written in C90. So the proper solution is to   
   > > write PDOS/3X0 and that is already underway.   
      
   > For new code there is no reason to stay with limitations   
   > of 370. Why do not you go direcly to s390 mode?   
      
   S/370, or even S/360, is the "lowest common denominator"   
   for 32-bit registers.   
      
   I am happy to provide the C source code so that other   
   people who want to use the S/390-only instructions can   
   recompile.   
      
   > It seems that your PDOS needs much more memory just for   
   > single user. And list of supported commands looks very   
   > short...   
      
   It uses less than 32 MiB for everything that I am   
   interested in, and the vast bulk of memory usage   
   is consumed by GCC 3.2.3 which I have no easy   
   control over (or solution for), so I am perfectly   
   satisfied with PDOS/3X0 (and PDOS/386 for   
   that matter, other than the bugs).   
      
   > > > If you look at technical problems, in a sense biggest   
   > > > one is endiannes, as one needs extra instructions to   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)