camel-cdr

🐘 @[email protected]

[camel-cdr @CamelCdr]

@FelixCLC_ There are some other things to consider, for example FP is usually 3R1W and integer 2R1W. But afaik 3R1W is usually implemented with port stealing or late forwarding for FMA to reduce the actual port count.

[camel-cdr @CamelCdr]

I feel like overlapping FP and integer physical register file and ports may be better than overlapping FP with SIMD.

Because scalar FP needs higher issue and lower latency than SIMD FP.

[camel-cdr @CamelCdr]

@FelixCLC_ Overlapping FP and INT also gives you have more control over FP32 and FP64. Maybe you put FP32 on all ALUs, but FP64 only on the ones that also support IMUL (if you can share that logic).

[camel-cdr @CamelCdr]

@FelixCLC_ Imagine not beeing able to force your self to implement your own ISA extension.

[camel-cdr @CamelCdr]

@corsix @FUZxxl First chapter

[camel-cdr @CamelCdr]

@mu_chrinovic That's not the only one, they had multiple 10K bounties for what would be the most trivial stuff on sane architectures.

[camel-cdr @CamelCdr]

@mu_chrinovic Tell me your compiler isn't working, without telling me your compiler isn't working.

[camel-cdr @CamelCdr]

yes, this is good, more of that please

This is a lot better than the alternative of a bunch of people crating their own incompatible subsets.

[Pete Cawley @corsix]

Someone looked at the overlapping mess of AVX512 extensions and thought “yes, that is good, more of that please”

[camel-cdr @CamelCdr]

@corsix The current AME draft is having fun with it, how about we allow people to implement all floating-point types:

[camel-cdr @CamelCdr]

@FelixCLC_ Sadly I wasn't able to find a L2 miss perf counter. That would've also been interesting, because predecode isn't relevant there.

[camel-cdr @CamelCdr]

@FelixCLC_
I tested the impact of disabling RVC on the SpacemiT X100 4-wide OoO core with clang.
Enabling RVC resulted in a roughly 10% performance improvement.
Not sure what this actually tells us about RVC exactly, but it's certainly interesting.

[camel-cdr @CamelCdr]

@FelixCLC_ Since it's a modified OpenC910, it should have a 64 KiB 4-way associative L1I, with 4-bit of pre-decode for every 16-bit slot. Two of which indicate size, though idk why that duplicates the prefix. You would only need 2-bit for every 32-bit slot in an implementation without RVC.

[camel-cdr @CamelCdr]

@FelixCLC_ The instruction pack stage, which resolves the ICache ways and does further pre-decoding before 16-bit parcels + metadata get written to the instruction queue. But doesn't do the alignment.

https://t.co/blLIGFXz2G

[camel-cdr @CamelCdr]

@FelixCLC_ The C910 C&C article suggests, decode cracking and alignment happens in one decode pipeline stage. The X100 doesn't need to crack anything at high performance (LMUL is handled later and it doesn't support xthead), so I assume they rewrote that part with some fusion logic instead.

[camel-cdr @CamelCdr]

The L1I bandwidth of the X100 is 16-bytes / cycle, so it should be able to feed the 4-wide core without compressed instruction.
While the X100 supports a handful of fusion pairs, those aren't compressed only. (bitwise+bitwise, mul+add, add+load/store, slli+sr*i)

[camel-cdr @CamelCdr]

@geofflangdale @InstLatX64 sha3 in particular is probably a bad example, because the algorithm was exlicitly designed for 32 GPRs.
But yeah, excited for APX.

[camel-cdr @CamelCdr]

@InstLatX64 The other real world benefit is making emulating x86 on other ISAs slower.

[camel-cdr @CamelCdr]

@FUZxxl This one is also interesting: https://t.co/bASr0arQZI

[camel-cdr @CamelCdr]

@FUZxxl The author of that recentlt publishes their dissertation, which is also quite interesting: https://t.co/xRkOrOeDEG