Path: ...!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: My 66000 and High word facility
Date: Mon, 19 Aug 2024 15:29:48 -0500
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <va09vs$30cgt$1@dont-email.me>
References: <v98asi$rulo$1@dont-email.me>
 <38055f09c5d32ab77b9e3f1c7b979fb4@www.novabbs.org>
 <v991kh$vu8g$1@dont-email.me> <2024Aug11.163333@mips.complang.tuwien.ac.at>
 <v9b57p$2rkrq$1@dont-email.me> <v9brm4$33kmd$1@dont-email.me>
 <e369e386b23628e5388e95b5a92af62d@www.novabbs.org>
 <v9jij9$lk6a$1@dont-email.me> <v9jjjn$lofu$1@dont-email.me>
 <v9k38n$rg2a$1@dont-email.me> <v9mklt$1air0$1@dont-email.me>
 <1bf2c13fc41cf8aeca4a746052c03ce3@www.novabbs.org>
 <v9oqjo$1k775$1@dont-email.me> <v9pkdh$1r0i3$2@dont-email.me>
 <v9r1sn$21mtt$1@dont-email.me> <v9r6qf$22f31$1@dont-email.me>
 <dc02cb510fa978ca8fe93d9cbf2b3493@www.novabbs.org>
 <v9s4lq$29u4s$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 19 Aug 2024 22:29:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="25af7dd0d2bba00686d7dce6357b84cd";
	logging-data="3158557"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+C9a6dVwJMieKDGkH9OQluHIrxoj/tg98="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:b5eOmWjUkd0PD2i15N+MEOlyPNM=
In-Reply-To: <v9s4lq$29u4s$1@dont-email.me>
Content-Language: en-US
Bytes: 4943

On 8/18/2024 1:34 AM, Thomas Koenig wrote:
> MitchAlsup1 <mitchalsup@aol.com> schrieb:
> 
>> Based on the code I read out of Brian's compiler: there is no particular
>> need for 64-registers. I am already using only 72% of the instructions
>> {72% average, 70% geomean, 69% harmonic mean} that RISC-V requires
>> {same compiler, same optimizations, just different code generators}.
> 
> That's true - the code is usually expressed as a very straightforward
> translation of the original code, at least for C.
> 
> Register pressure will increase for unrolling of outer loops,
> for languages which use dope vectors (aka array descriptors),
> and for more aggressive inlining.
> 

Or, for functions working with 100+ local variables in a loop...

In my case, I have non-zero amounts of code like this.


Might also be better if my compiler didn't suck so bad, as in many cases 
it can only really use half of the available registers:
   Will not static-assign variables to scratch registers;
   Will not use scratch registers for variables in non-leaf blocks.


But, if a variable is in a scratch register and we need to load function 
arguments and there is a conflict, there is a problem (excluding a GCC 
style register allocator that is seemingly able to "know the future" and 
assign registers in advance such that no conflict will happen and 
nothing needs to be spilled).


> Consider an argument passed as an assumed-shape array in
> Fortran.
> 
>    subroutine foo(a)
>      real, dimension(:,:)
>   
> where the array assumes the shape from the caller,
> two-dimensional in this case.
> 
> For passing such an array, we need a base pointer and
> information about
> 
> - the lower bound
> - the  upper bound
> - the stride
> 
> along each dimension, so it is 7 quantities in ths case.
> 

In my case, it is hit/miss between an 8-argument ABI and 16 argument ABI.

When building code in a mode that uses 64 GPRs, often the 16 argument 
ABI has ended up being used, but depends.

So, say:
   Baseline: Defaults to 32 GPRs Only
   Baseline+XGPR: Command-line flag, either 8 or 16 argument ABI
   XG2: Defaults to 64 GPRs with 16-argument ABI.

Generally:
   Boot ROM: Baseline
   Kernel: Baseline+XGPR
     Technical reasons mostly.
   Various programs: Often XG2.


> 
>> One can argue that having 64-bit displacements is not-all-that-necessary
>> But how does one take dusty deck FORTRAN FEM programs and allow the
>> common blocks to grow bigger than 4GBs ?? This is the easiest way
>> to port code written 5 decades ago to use the sizes of memory they
>> need to run those "Great Big" FEM models today.
> 
> That is certainly one reason. Another is being able to have
> a "huge" model with code > 2GB without too much effort.
> Programs _are_ getting bigger...
> 
>>> Of course, it might be possible to code FMA like AVX does, with
>>> only three registers - 18 bits for three registers, plus two bits
>>> for which one of them gets smashed for the result.
>>
>> Why do I get the feeling the compiler guys would not like this ??
> 
> Because they won't? :-)  It is certainly more straightforward
> this way.

The 4R case makes more sense as a 64-bit encoding.

....