| Deutsch English Français Italiano |
|
<v0kodk$t520$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!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: Stealing a Great Idea from the 6600 Date: Sun, 28 Apr 2024 00:56:01 -0500 Organization: A noiseless patient Spider Lines: 371 Message-ID: <v0kodk$t520$1@dont-email.me> 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> <3458ae0a6b7c1f667ef232c58569b5e1@www.novabbs.org> <v0k2kb$l21r$1@dont-email.me> <58f8e9f6925fd21a5526ea45fae82251@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 28 Apr 2024 07:56:05 +0200 (CEST) Injection-Info: dont-email.me; posting-host="437e2caa7a0d326db2a3a89ac4546326"; logging-data="955456"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX185zDtBAa83xK6ptuxq0nu8GVxfBO3Eyok=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:qrDgnCfn4mmHshQJLeMzYx3C5VE= Content-Language: en-US In-Reply-To: <58f8e9f6925fd21a5526ea45fae82251@www.novabbs.org> Bytes: 14450 On 4/27/2024 8:45 PM, MitchAlsup1 wrote: > BGB wrote: > >> On 4/27/2024 3:37 PM, MitchAlsup1 wrote: >>> 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 ?? >>> > >> It would appear that, with my current compiler output, both BJX2-XG2 >> and RISC-V RV64G are within a few percent of each other... > >> If adjusting for Jumbo prefixes (with the version that omits GBR >> reloads): >> XG2: 270K (-10K of Jumbo Prefixes) > >> Implying RISC-V now has around 11% more instructions in this scenario. > > Based on Brian's LLVM compiler; RISC-V has about 40% more instructions > than My 66000, or My 66000 has 70% the number of instructions that > RISC-V has (same compilation flags, same source code). > I have made some progress here recently, but it is still a case of (in my case): Stronger ISA, but with a compiler with a weak optimizer; Vs: Weaker ISA, but vs a compiler with a stronger optimizer. GCC is very clever at figuring out what to optimize... Meanwhile, BGBCC may fail to optimize away constant sub-expressions if operator precedence doesn't fall in a preferable direction. Say: y=x*3*4; Doing two multiply instructions in a row, because: y=x*12; Didn't happen to map to the AST as it was written (because parsing was left-associative in this case). Yeah, actually ran into this recently, only solution at present is to put parenthesis around the constant parts. But, yeah, seemingly GCC isn't fooled by things like precedence order. Seemingly, it may even chase constants across basic blocks or across memory loads and stores, causing chunks of code to disappear, etc... But, still not enough to make up for RV64G's weaknesses it seems. Well, and Doom isn't full of a lot of cases for it to leverage its seeming aggressive constant-folding might... >> It also has an additional 20K of ".rodata" that is likely constants, >> which likely overlap significantly with the jumbo prefixes. > > My 66000 has vastly smaller .rodata because constants are part of .text > Similar, though in my case they exist as Jumbo prefixes. Except well, if values are declared as "const double x0=...;", where BGBCC ends up treating it like a normal variable that does not allow assignment (so will generate different code than had one used #define or similar). Also noted cases of this recently when diffing through my compiler output. Does seem to be context-dependent to some extent though... >>>> 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 ?? >>> > >> Required a little digging: "Function Descriptor Position Independent >> Code". > >> But, I think the main difference is that, normal PIC does calls like >> like: >> LD Rt, [GOT+Disp] >> BSR Rt > > CALX [IP,,#GOT+#disp-.] > > It is unlikely that %GOT can be represented with 16-bit offset from IP > so the 32-bit displacement form (,,) is used. > >> Wheres, FDPIC was typically more like (pseudo ASM): >> MOV SavedGOT, GOT >> LEA Rt, [GOT+Disp] >> MOV GOT, [Rt+8] >> MOV Rt, [Rt+0] >> BSR Rt >> MOV GOT, SavedGOT > > Since GOT is not in a register but is an address constant this is also:: > > CALX [IP,,#GOT+#disp-.] > So... Would this also cause GOT to point to a new address on the callee side (that is dependent on the GOT on the caller side, and *not* on the PC address at the destination) ?... ========== REMAINDER OF ARTICLE TRUNCATED ==========