muta...@gmail.com wrote:
> 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.
Apparently you are quite good at negotiating extemptions
for yourself. 16-bit mode usually will give you more
performance loss than 10% compared to 32-bit mode.
And using 370 mode on 390 will significantly cut
in your 10% budget (maybe even exceed it). Unless
you mean 10% per excuse, but in such case your
limit would be meaningless (with 22 excuses you
could justify 10 times slowdown).
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. 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%).
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.
From different angle, recoding small speed-critical
parts in assembler can give you mor than 10% speedup.
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.
> > 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.
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.
> > 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.
I mean s390 gcc (as opposite to 370). s390 was
able to rebuild itself (I did rebuild it and there
were no trouble). But reload issue showed up as
one of test programs not working (I run extra
tests, more beyond gcc testsuite).
Anyway, if you did not run the testsuite, than
your port has rather dubious status, I certainly
would not consider it finished.
> 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.
> > > 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? 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?
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.
> > > Not sure what you're talking about there. 80386
> > > endianness is already proven technology.
>
> > 80386 endianness is little. 360 endianness is big. Look
> > at functions like:
> >
> > int
> > foo(int x) {
> > char a[sizeof(x)];
> > memcpy(a, &x, sizeof(x));
> > return a[0];
> > }
> >
> > AFAIK this is kosher C90 code which will give different
> > results depending on endianness. It may look unnatural
> > to you, but simiar codes appear quite naturally when
> > handling data from binary files.
>
> 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.
> > > > However, for specific
> > > > tasks C code could be written in including explicit
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
