4 ms·

The Qualcomm online defenders are something else too. Qualcomm have been acting badly for years, including attempting to turn RISC-V into Arm64 but without the

The Qualcomm online defenders are something else too. Qualcomm have been acting badly for years, including attempting to turn RISC-V into Arm64 but without the restrictions. You cannot trust people that behave like this, where everything they do is important and everything you do is worthless. The funny thing is Qualcomm do have some wildly impressive tech which is kept secret despite being so ubiquitous, but they have had persistent execution failures at integrations which lead to them throwing their partners under the bus. Qualcomm have the same sort of corporate difficulty you see at Boeing, only in a less high profile sector.

eqvinox 2y ago
> attempting to turn RISC-V into Arm64 but without the restrictions This flew past me, do you have a link?
- fidotron 2y ago
  Brucehoult mentions it further down. > This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite. This is enough of a philosophy change to break existing RISC-V software, and so is purely motivated by a desire to clone IP they supposedly licensed as honest brokers.
  - rangestransform 2y ago
    Not a cpu designer, but aren’t variable length instructions a big part of why x86 decoders take up so much area, and also increases branch predictor complexity?
    - wbl 2y ago
      So much is relative: on a giant OoO core it's barely noticeable. In the case of x86 the range of lengths is extreme: a simple two or four choice is much simpler.
    - jecel 2y ago
      The RISC-V creators were aware of the issues when they designed the C extension with 16 bit instructions to be able to compete with ARM's Thumb. So the bottom two bits of an instruction are enough to distinguish between 16 bit and 32 bit encodings (the standard has a scheme for future longer instructions, but hardware that doesn't implement them can ignore that). This means that if a RISC-V reads a 16 byte block from instruction memory, it only has to look at 8 pairs of bits. This would require 8 NAND gates plus 8 more NANDs to ignore the top half of any 32 bit instructions. That is 4x(8+8)=64 transistors. The corresponding circuit for x86 would be huge. But note that this just separates the instructions. You still have to decode them. Most simple RISC-V implementations have a circuit that transforms each 16 bit instruction into the corresponding 32 bit one, which is all the rest of the processor has to deal with. Here are the sizes of some such circuits: Hazard 3: 733 NANDs (used in the Raspberry Pi RP2350) SERV: 532 NANDs (serial RISC-V) Revive: 506 NANDs (part of FPGAboy) You would need 8 such circuits to handle the maximum 16 bit instructions in a 16 byte block, and then you would need more circuits to decode the resulting 32 bit instructions. So the 16 NANDs to separate the variable length instructions is not a problem like it is for other ISAs. The problem with 16 bit instructions for small RISC-V implementations is that now 32 bit instructions will not always be aligned with 32 bit words. Having to fetch an instruction from two separate words adds circuits that can be a large fraction of a small design.
    - dzaima 2y ago
      x86 specifically is extra awful to decode because there's no easy way to tell the instruction length without doing a good portion of the decode process, so it ends up needing to attempt to decode at each byte offset. Valid lengths being all between 1 and 15 doesn't help. So processing a fetched 16 bytes requires doing 16 partial decodes, each of them non-trivial (skip over unordered prefix bytes; parse fixed prefix before opcode (most bytes are the opcode immediately, except 0x0F, 0xC4, 0xC5, and more for rarer instructions & AVX-512/APX, which have extra skipping necessary); index a LUT by the opcode (with a different table for the 0x0F case, and maybe more cases idk; plus maybe some more length depending on byte after opcode; for some opcodes the length even depends on if a specific prefix byte was given, which intel just assumes doesn't happen and behaves slowly if it does); if the opcode needs ModR/M, also parse that from the next byte (another variable-length sequence)).
  - starspangled 2y ago
    I don't really see how this follows. Fixed length instructions are a well known and highly desirable property for instruction decoders (at the cost of some density), which has been known about and done since the first RISCs. And ARMv8 is basically just a warmed-over RISC with very little new or innovative in there. It's just an ISA. ARM Ltd is basically rent-seeking on keeping the ISA proprietary, same as Intel and AMD do. Sure it's a highly specialized and very impressive task to make an ISA, but not to the value of extracting hundreds of millions of dollars ever year. If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy.
    - ksec 2y ago
      >If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy. ARM never said that. >but not to the value of extracting hundreds of millions of dollars ever year. ARM makes money on selling ARM design, not from their ISA licensing.
      - starspangled 2y ago
        > ARM never said that. Someone did. > ARM makes money on selling ARM design, not from their ISA licensing. That's not correct, they make money from ISA licensing. That's called their architectural license, and that is what is being canceled here.
GeekyBear 2y ago
> throwing their partners under the bus I found it telling that every single smartphone vendor refused to license Qualcomm's proprietary tech for smartphone to satellite messaging. > In a statement given to CNBC, Qualcomm says smartphone makers “indicated a preference towards standards-based solutions” for satellite-to-phone connectivity https://arstechnica.com/gadgets/2023/11/qualcomm-kills-its-copy-of-apples-satellite-sos-after-ten-months/ https://arstechnica.com/gadgets/2023/11/qualcomm-kills-its-c...
- xg15 2y ago
  "We're disinclined to acquiesce to your request. Means 'no'."
- throwup238 2y ago
  Anyone only ever uses Qualcomm chips because they have a gun to their head. Usually that gun is the latest wireless standard like 4g or 5g.
  - GeekyBear 2y ago
    4g and 5g are open standards. It was their now mostly irrelevant CDMA patents that Qualcomm used as a weapon against device makers. > Many carriers (such as AT&T, UScellular and Verizon) shut down 3G CDMA-based networks in 2022 and 2024, rendering handsets supporting only those protocols unusable for calls, even to 911. https://en.m.wikipedia.org/wiki/Code-division_multiple_access https://en.m.wikipedia.org/wiki/Code-division_multiple_acces... In my opinion, Qualcomm's abuse of their CDMA patents is the reason that zero device makers were willing to get on board with a new Qualcomm proprietary technology.
    - Kirby64 2y ago
      They’re open standards, sure, but there is almost no competition in the cellular modem space. Intel tried and failed spectacularly. Apple bought the scraps of the Intel modem business and still hasn’t released their own modems after… 5 years? Cellular tech is hard and has a lot of esoteric requirements. If you want a cell modem for a smartphone, you essentially buy either the latest and greatest from Qualcomm or you buy something from one of the Chinese companies (Huawei, Mediatek) which has its own set of problems.
mocenigo 2y ago
[dead]

eqvinox 2y ago

> attempting to turn RISC-V into Arm64 but without the restrictions This flew past me, do you have a link?

fidotron 2y ago
Brucehoult mentions it further down. > This time last year they were all over the RISC-V mailing lists, trying to convince everyone to drop the "C" extension from RVA23 because (basically confirmed by their employees) it was not easy to retrofit mildly variable length RISC-V instructions (2 bytes and 4 bytes) to the Aarch64 core they acquired from Nuvia. At the same time, Qualcomm proposed a new RISC-V extension that was pretty much ARMv8-lite. This is enough of a philosophy change to break existing RISC-V software, and so is purely motivated by a desire to clone IP they supposedly licensed as honest brokers.
- rangestransform 2y ago
  Not a cpu designer, but aren’t variable length instructions a big part of why x86 decoders take up so much area, and also increases branch predictor complexity?
  - wbl 2y ago
    So much is relative: on a giant OoO core it's barely noticeable. In the case of x86 the range of lengths is extreme: a simple two or four choice is much simpler.
  - jecel 2y ago
    The RISC-V creators were aware of the issues when they designed the C extension with 16 bit instructions to be able to compete with ARM's Thumb. So the bottom two bits of an instruction are enough to distinguish between 16 bit and 32 bit encodings (the standard has a scheme for future longer instructions, but hardware that doesn't implement them can ignore that). This means that if a RISC-V reads a 16 byte block from instruction memory, it only has to look at 8 pairs of bits. This would require 8 NAND gates plus 8 more NANDs to ignore the top half of any 32 bit instructions. That is 4x(8+8)=64 transistors. The corresponding circuit for x86 would be huge. But note that this just separates the instructions. You still have to decode them. Most simple RISC-V implementations have a circuit that transforms each 16 bit instruction into the corresponding 32 bit one, which is all the rest of the processor has to deal with. Here are the sizes of some such circuits: Hazard 3: 733 NANDs (used in the Raspberry Pi RP2350) SERV: 532 NANDs (serial RISC-V) Revive: 506 NANDs (part of FPGAboy) You would need 8 such circuits to handle the maximum 16 bit instructions in a 16 byte block, and then you would need more circuits to decode the resulting 32 bit instructions. So the 16 NANDs to separate the variable length instructions is not a problem like it is for other ISAs. The problem with 16 bit instructions for small RISC-V implementations is that now 32 bit instructions will not always be aligned with 32 bit words. Having to fetch an instruction from two separate words adds circuits that can be a large fraction of a small design.
  - dzaima 2y ago
    x86 specifically is extra awful to decode because there's no easy way to tell the instruction length without doing a good portion of the decode process, so it ends up needing to attempt to decode at each byte offset. Valid lengths being all between 1 and 15 doesn't help. So processing a fetched 16 bytes requires doing 16 partial decodes, each of them non-trivial (skip over unordered prefix bytes; parse fixed prefix before opcode (most bytes are the opcode immediately, except 0x0F, 0xC4, 0xC5, and more for rarer instructions & AVX-512/APX, which have extra skipping necessary); index a LUT by the opcode (with a different table for the 0x0F case, and maybe more cases idk; plus maybe some more length depending on byte after opcode; for some opcodes the length even depends on if a specific prefix byte was given, which intel just assumes doesn't happen and behaves slowly if it does); if the opcode needs ModR/M, also parse that from the next byte (another variable-length sequence)).
- starspangled 2y ago
  I don't really see how this follows. Fixed length instructions are a well known and highly desirable property for instruction decoders (at the cost of some density), which has been known about and done since the first RISCs. And ARMv8 is basically just a warmed-over RISC with very little new or innovative in there. It's just an ISA. ARM Ltd is basically rent-seeking on keeping the ISA proprietary, same as Intel and AMD do. Sure it's a highly specialized and very impressive task to make an ISA, but not to the value of extracting hundreds of millions of dollars ever year. If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy.
  - ksec 2y ago
    >If ARM gets upset because someone wanted fixed-length instructions standardized in RISCV that's really the height of hypocrisy. ARM never said that. >but not to the value of extracting hundreds of millions of dollars ever year. ARM makes money on selling ARM design, not from their ISA licensing.
    - starspangled 2y ago
      > ARM never said that. Someone did. > ARM makes money on selling ARM design, not from their ISA licensing. That's not correct, they make money from ISA licensing. That's called their architectural license, and that is what is being canceled here.

GeekyBear 2y ago

> throwing their partners under the bus I found it telling that every single smartphone vendor refused to license Qualcomm's proprietary tech for smartphone to satellite messaging. > In a statement given to CNBC, Qualcomm says smartphone makers “indicated a preference towards standards-based solutions” for satellite-to-phone connectivity https://arstechnica.com/gadgets/2023/11/qualcomm-kills-its-copy-of-apples-satellite-sos-after-ten-months/ https://arstechnica.com/gadgets/2023/11/qualcomm-kills-its-c...

xg15 2y ago
"We're disinclined to acquiesce to your request. Means 'no'."
throwup238 2y ago
Anyone only ever uses Qualcomm chips because they have a gun to their head. Usually that gun is the latest wireless standard like 4g or 5g.
- GeekyBear 2y ago
  4g and 5g are open standards. It was their now mostly irrelevant CDMA patents that Qualcomm used as a weapon against device makers. > Many carriers (such as AT&T, UScellular and Verizon) shut down 3G CDMA-based networks in 2022 and 2024, rendering handsets supporting only those protocols unusable for calls, even to 911. https://en.m.wikipedia.org/wiki/Code-division_multiple_access https://en.m.wikipedia.org/wiki/Code-division_multiple_acces... In my opinion, Qualcomm's abuse of their CDMA patents is the reason that zero device makers were willing to get on board with a new Qualcomm proprietary technology.
  - Kirby64 2y ago
    They’re open standards, sure, but there is almost no competition in the cellular modem space. Intel tried and failed spectacularly. Apple bought the scraps of the Intel modem business and still hasn’t released their own modems after… 5 years? Cellular tech is hard and has a lot of esoteric requirements. If you want a cell modem for a smartphone, you essentially buy either the latest and greatest from Qualcomm or you buy something from one of the Chinese companies (Huawei, Mediatek) which has its own set of problems.

mocenigo 2y ago

[dead]