From: muta...@gmail.com   
      
   On Friday, August 13, 2021 at 10:58:56 PM UTC+10, anti...@math.uni.wroc.pl   
   wrote:   
      
   > > > Hmm, you in several places rejected various possible   
   > > > solutions as too inefficient or too complex. So,   
   > > > how much inefficiency is acceptable?   
   > >   
   > > 10%, negotiable.   
      
   > Apparently you are quite good at negotiating extemptions   
   > for yourself.   
      
   The exemptions are not for myself. They are for others   
   who want to slow my code down by using paging or   
   anything else.   
      
   > 16-bit mode usually will give you more   
   > performance loss than 10% compared to 32-bit mode.   
      
   Those are completely different competitions, like   
   competing with ARM.   
      
   > And using 370 mode on 390 will significantly cut   
   > in your 10% budget (maybe even exceed it).   
      
   No, that's like ARM too. The 10% is S/370 with or   
   without paging. The 10% is S/390 with or without   
   paging. Or running things in problem mode instead   
   of supervisor mode. Or vice-versa.   
      
   > And you have "interesting" interpretation for memory   
   > use: what your PDOS/370 is doing could be done in 256k   
   > memory, leaving rest for applications, but you take   
   > much more.   
      
   My reference point is 4 GiB, not 256k.   
      
   > And ignoring I/O is means that you are   
   > really not interested in practice: efficient handling   
   > of I/O is important part of what O/S is doing.   
   > As a user I look at time from start to finish, and   
   > better I/O handling makes visible difference (much   
   > more than 10%).   
      
   No. In any work I do, all of the disk datasets will be   
   cached in memory.   
      
   > And you mention gcc above. If gcc compiles too slow   
   > for you there are faster compilers. Bart in comp.lang.c   
   > provoded you with a compiler that compiles many times   
   > faster than gcc, at the cost of slower speed of generated   
   > code.   
      
   No. gccmvs is my reference.   
      
   > From different angle, recoding small speed-critical   
   > parts in assembler can give you mor than 10% speedup.   
      
   No. I want gccmvs to be unchanged. You can add   
   or remove paging at the OS level. You can add or   
   remove caching at the OS level. But the application   
   is to remain unchanged. It's being used as a reference.   
      
   > And when critical part are in assember you can   
   > afford much slower bulk of code (naive compiler or   
   > even interpreted). But C90 is clearly more important   
   > for you than "small" inefficiency.   
      
   Yes, I'm only interested in C90, not assembler kludges.   
      
   > The problem is clearly releated, but it is still   
   > not clear if this is the same problem. If you   
   > really "unconditionally load the base register",   
   > then this will solve problem that I mentioned,   
   > but issue was more subtle: once procedure was   
   > bigger than 4k, gcc was reloading base register   
   > and in first approximation this worked fine.   
   > However reloads of base register made code   
   > bigger which means sometimes more reloads were   
   > needed. gcc tried to handle those extra   
   > reloads but sometimes did it wrong.   
      
   This could have been the i370 situation too. I don't   
   remember and didn't look any further once I had a   
   reasonable solution.   
      
   > Anyway, if you did not run the testsuite, than   
   > your port has rather dubious status, I certainly   
   > would not consider it finished.   
      
   It isn't finished. I don't even know how to get rid of   
   the negative indexes which are preventing me from   
   running my 32-bit programs as AM64. I am forced   
   to run as AM32 instead.   
      
   > > One guy (Dave Wade) fried something like 3   
   > > CPUs in the process of endlessly rebuilding GCC   
   > > (on CMS).   
      
   > fried??? I did a lot of compilations in Intel   
   > machine, and while I had case that i saw   
   > machine failures, this was faulty machines   
   > (one notorius problem were marginal memory chips,   
   > in other case inadequate cooling of I/O chip).   
   > But I never saw compilations causing wear or   
   > machine failures. IBM has reputaion for   
   > quality and good workmanship, so that sound   
   > very strange.   
      
   IBM is not involved. He was continuously rebuilding   
   GCCCMS under Hercules, I think on an Intel.   
      
   And the CPU failures were real. There is no definitive   
   proof that the GCCCMS work caused it though.   
      
   > > > > 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.   
      
   > Well, you ignore real-life issues. And what "native   
   > speed" means exactly?   
      
   Bochs interprets 80386 instructions. That is not native   
   speed.   
      
   Qemu translates 80386 instructions. That is not native   
   speed.   
      
   Virtualbox, and WoW mode are a bit odd, but close enough   
   to native speed. I think I saw someone claim that Virtualbox   
   was 3% slower.   
      
   > On my machine 'strcpy' and   
   > even 'sprintf' works at 6.5 character per cycle   
   > when handling long strings. Can you get such speed   
   > from code compatible whith 8086? Or even from   
   > C90 code compiled by gcc-3.2.3?   
      
   Once C90 code is in place, I don't mind having   
   *optional* assembler speedups.   
      
   > FYI, fast 'strcpy' is possible due to SSE instructions.   
   > I am not sure how library code looks like, but modern   
   > gcc can generate SSE instructions from plain C code.   
   > Code avoiding SSE can be 2, 4 or even 16 times slower.   
      
   So recompile with SSE instructions. That's the   
   beauty of C source code.   
      
   > > No, if you follow the C90 rules, that will produce   
   > > undefined behavior. I don't have things like that in   
   > > my code, even for binary files like the FAT file   
   > > system. I'm not interested in supporting that.   
      
   > You can ask in comp.lang.c. But AFAIK there is no undefined   
   > behaviour, just code which gives different results on   
   > different machines.   
      
   You can ask if you want. The different results are   
   because you are breaking the C90 rules. I'm not   
   interested in such code. You're free to have a   
   non-default #ifdef to activate that code if you want   
   though.   
      
   > You had doubts if convertion to EBCDIC will work for   
   > i386 target. What I am saying is that you can easily   
   > solve problem outside compiler (which for example   
   > could allow different compiler than gcc). Anyway,   
   > it is for you to decide if there is a problem to   
   > solve or not.   
      
   As I explained, I'm expecting atoi() to operate on   
   x'F1F2F3'. To date, I've never witnessed an 80386   
   do such a thing, at least not as part of the C library.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)