Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Stealing a Great Idea from the 6600
Date: Sat, 27 Apr 2024 20:37:34 +0000
Organization: Rocksolid Light
Message-ID: <3458ae0a6b7c1f667ef232c58569b5e1@www.novabbs.org>
References: <dd1866c4efb369b7b6cc499d718dc938@www.novabbs.org> <acq62j98dhmguil5ebce6lq4m9kkgt1fs2@4ax.com> <kkq62jppr53is4r70n151jl17bjd5kd6lv@4ax.com> <9d1fadaada2ec0683fc54688cce7cf27@www.novabbs.org> <v017mg$3rcg9$1@dont-email.me> <da6dc5fe28bb31b4c73d78ef1aac2ac5@www.novabbs.org> <sdl82jpkpf1t0ctr8sgqm5bvqqireg08j5@4ax.com> <44fdd1209496c66ba18e425370a8b50d@www.novabbs.org> <ks8e2j1kquqpcupcgh32es7nci33nlajid@4ax.com> <ec69999967361c286afdbe60bc2443ea@www.novabbs.org> <dtel2j5kipf6tj9cabgp7pqk8eei14eo1a@4ax.com> <v0euek$3a2rc$1@dont-email.me> <ff78aaa73101509100f09f190838a2a7@www.novabbs.org> <IQSWN.4$nQv.0@fx10.iad> <v0jlf3$i3mh$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2561816"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$IAFkvKc85GmfqRSVAoUDs.h3zmEZkEX11Os.TSepVbVmitTtL9FxC
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4510
Lines: 79

BGB wrote:

> On 4/26/2024 1:59 PM, EricP wrote:
>> MitchAlsup1 wrote:
>>> BGB wrote:
>>>
>>>> If one had 16-bit displacements, then unscaled displacements would 
>>>> make sense; otherwise scaled displacements seem like a win 
>>>> (misaligned displacements being much less common than aligned 
>>>> displacements).
>>>
>>> What we need is ~16-bit displacements where 82½%-91¼% are positive.
>>>
>>> How does one use a frame pointer without negative displacements ??
>>>
>>> [FP+disp] accesses callee save registers
>>> [FP-disp] accesses local stack variables and descriptors
>>>
>>> [SP+disp] accesses argument and result values
>> 
>> A sign extended 16-bit offsets would cover almost all such access needs
>> so I really don't see the need for funny business.
>> 
>> But if you really want a skewed range offset it could use something like
>> excess-256 encoding which zero extends the immediate then subtract 256
>> (or whatever) from it, to give offsets in the range -256..+65535-256.
>> So an immediate value of 0 equals an offset of -256.
>> 

> Yeah, my thinking was that by the time one has 16 bits for Load/Store 
> displacements, they could almost just go +/- 32K and call it done.

> But, much smaller than this, there is an advantage to scaling the 
> displacements.




> In other news, got around to getting the RISC-V code to build in PIE 
> mode for Doom (by using "riscv64-unknown-linux-gnu-*").

> Can note that RV64 code density takes a hit in this case:
>    RV64: 299K (.text)
>    XG2 : 284K (.text)

Is this indicative that your ISA and RISC-V are within spitting distance 
of each other in terms of the number of instructions in .text ?? or not ??

> So, apparently using this version of GCC and using "-fPIE" works in my 
> favor regarding code density...


> I guess a question is what FDPIC would do if GCC supported it, since 
> this would be the closest direct analog to my own ABI.

What is FDPIC ?? Federal Deposit Processor Insurance   Corporation ??
                 Final   Dopey   Position  Independent Code ??

> I guess some people are dragging their feet on FDPIC, as there is some 
> debate as to whether or not NOMMU makes sense for RISC-V, along with its 
> associated performance impact if used.

> In my case, if I wanted to go over to simple base-relocatable images, 
> this would technically eliminate the need for GBR reloading.

> Checks:
> Simple base-relocatable case actually currently generates bigger 
> binaries, I suspect because in this case it is less space-efficient to 
> use PC-rel vs GBR-rel.

> Went and added a "pbostatic" option, which sidesteps saving and 
> restoring GBR (making the simplifying assumption that functions will 
> never be called from outside the current binary).

> This saves roughly 4K (Doom's ".text" shrinks to 280K).

Would you be willing to compile DOOM with Brian's LLVM compiler and
show the results ??

> ....