Chinese semiconductor thread II

gelgoog

Lieutenant General
Registered Member
Baget OS has a different use case. It is good enough to use in military or security critical systems.

The main developers behind ReactOS (a Windows clone) are also from Russia.
But I would say the main consumer OSes they use like Aurora OS are Linux clones yes.
 

tokenanalyst

Brigadier
Registered Member

The semiconductor ultrapure fluid accessories manufacturing project of Hengke New Materials (Jiangsu) Co., Ltd. started construction.​


The total investment of Henke Semiconductor Ultrapure Fluid Accessories Project is 516 million yuan, with a land area of 38.6 acres, located in Taizhou Comprehensive Bonded Zone. It mainly develops and produces industrial new material pipeline products, which are widely used in electronic semiconductors, photovoltaic solar energy, new energy, chemical industry, medical industry ultrapure fluid systems and other fields, focusing on providing an international leading one-stop product service platform for industrial pipeline fluid systems. After the project is completed, the annual production capacity can reach 1 million sets of fluid parts, with an estimated annual sales revenue of 400 million yuan and tax revenue of 22 million yuan.

Please, Log in or Register to view URLs content!
 

tokenanalyst

Brigadier
Registered Member
Please, Log in or Register to view URLs content!

Slightly tangential but Russia maintainers have been banned from contributing to the Linux kernel and have been removed from the maintainers list. There is also pressure to remove HUAWEI maintainers which would be a large blow but they’re not doing so at this time.

IMO this is a big loss for both Russia and Linux. Russian maintainers have contributed significantly to Linux. Vice versa, Russia has no realistic domestic operating systems and uses forks of Linux for anything sensitive.

Update: I’m hearing from some of my developer friends in China that this is a pretty shocking move over there. They’re worried that China itself will be banned from maintaining the Linux kernel as well.

Pretty shit move all around IMO. Gonna end up with a Euro American Linux fork and a Sino Russian one and likely shitty kernel patches back and forth to try to maintain some kind of compatibility in the long run at this rate.
So now the Russians are going to use the Linux kernel rent free and not contribute nothing back, at least not directly.
 

curiouscat

Junior Member
Registered Member
So now the Russians are going to use the Linux kernel rent free and not contribute nothing back, at least not directly.
It’s not that easy. If it was you wouldn’t see shock in the Russian IT community. Being banned from contributing means that Russia will now be forced to manually merge and fix code when there’s a conflict with the main. They also have no say in the direction of the Linux kernel now which makes development even harder. This isn’t good for Russia.
 

tokenanalyst

Brigadier
Registered Member
It’s not that easy. If it was you wouldn’t see shock in the Russian IT community. Being banned from contributing means that Russia will now be forced to manually merge and fix code when there’s a conflict with the main. They also have no say in the direction of the Linux kernel now which makes development even harder. This isn’t good for Russia.
I don't want to deviate from this thread but a lot companies have their own forks of the kernel including Huawei and they contribute absolute zero to the community even if the license require them to do so. They just bundle in their own proprietary systems.
 

JPaladin32

New Member
Registered Member
The ISA is well designed for what it was intended to do. To be used by college hardware design classes on how to design modern CPUs. At UC Berkeley.


We joked about scaling all the way from embedded to server space when we originally delineated the ISA.

So you can go from RV32E all the way to RV128.

Little did we know how far the ISA would come. The biggest mistakes IMHO on the specification with regards to the server space are the lack of indexed memory addressing and performance with unaligned memory accesses. I did put those as desirable features on the initial specification, but the college students torpedoed that because it would have made their task of designing a CPU in a semester harder. So much for that.

I do think T-Head has some proprietary extensions which do add indexed memory addressing.
Please, Log in or Register to view URLs content!

As for Qualcomm, much of what they have claimed RISC-V should add or remove, is bullshit and a bad idea. They are just being lazy and trying to turn RISC-V into ARM. For example the variable length instructions in RISC-V. They are actually a great idea to compress code size so you need less i-cache and have less faults. I usually joke that RISC-V is the most CISCy RISC processor.

And it is not like there is anything preventing you from supporting unaligned memory accesses in your own hardware implementation. It is just that it isn't mandatory as part of the spec.

As for the lack of flags you can blame me. :)
I demanded that to be part of the architecture to make it easier to make OoO superscalar processors.

Another thing it could use, I guess, is a proper multiple register save and restore instruction. While we did consider it, back then I didn't know about the ARM instructions, I had never coded in ARM assembler myself, and the x86 register save instructions are kind of useless anyway.
On hindsight I am not even sure if ARM had those instructions back when we came up with the initial draft RISC-V spec.


You can get RISC-V to work for high-performance computing even with the regular ISA. You will need a wider processor because you will have more ops because of the lack of indexed memory addressing and other things. But it is not like it is impossible to do one.

Good evidence for this is that people like Jim Keller have looked at the architecture and think there is nothing majorly wrong with it.

The ISA is also so extensible that if something does become a major issue it can be added later. The latest RVA23 spec is way more complete than the initial RV64GC.

RISC-V is probably the only current architecture designed from the outset to be able to support hypervisors in the future. And it also has more features that other architectures lack despite being that simple. It was designed to be extensible from the start. With the variable length instructions you get even more ISA space without bloating the code size.

A lot of people claim that the latest RISC-V profile with the builtin instruction compression always provides the smallest binaries of the major architectures. Even compared with CISC x86-64. So that is something. A lot of people overly focus on reducing the amount of instructions instead of code size. But they forget that while logic continues to shrink, memory (particularly SRAM) is shrinking way slower. It is important to keep the memory footprint down. If you keep going outside of the cache size and need to fetch memory from DRAM you will also slow everything down.
Hmm, you must be someone I know (unless you have revealed who you are in this forum which sorry I haven't noticed because I just joined).

I do generally agree with what you said. Come on, let's add condition flags, just a couple of more addressing modes and maybe load-store pair instructions, but I disagree on compressed instructions. I like the code size savings, yes, but not what it does to the encoding space.

But to be honest, we ran our experiments and no matter how much I complain, RISC-V still beats x86 in several key metrics. If x86 can be made to work, RISC-V definitely can, although one would always hope that it could be better than what it is now.

Okay I'll stop hijacking this into a RISC-V thread : )
 

latenlazy

Brigadier
Hmm, you must be someone I know (unless you have revealed who you are in this forum which sorry I haven't noticed because I just joined).

I do generally agree with what you said. Come on, let's add condition flags, just a couple of more addressing modes and maybe load-store pair instructions, but I disagree on compressed instructions. I like the code size savings, yes, but not what it does to the encoding space.

But to be honest, we ran our experiments and no matter how much I complain, RISC-V still beats x86 in several key metrics. If x86 can be made to work, RISC-V definitely can, although one would always hope that it could be better than what it is now.

Okay I'll stop hijacking this into a RISC-V thread : )
Maybe you boys need your own RISC-V thread ;)
 

MortyandRick

Senior Member
Registered Member
Please, Log in or Register to view URLs content!

Slightly tangential but Russia maintainers have been banned from contributing to the Linux kernel and have been removed from the maintainers list. There is also pressure to remove HUAWEI maintainers which would be a large blow but they’re not doing so at this time.

IMO this is a big loss for both Russia and Linux. Russian maintainers have contributed significantly to Linux. Vice versa, Russia has no realistic domestic operating systems and uses forks of Linux for anything sensitive.

Update: I’m hearing from some of my developer friends in China that this is a pretty shocking move over there. They’re worried that China itself will be banned from maintaining the Linux kernel as well.

Pretty shit move all around IMO. Gonna end up with a Euro American Linux fork and a Sino Russian one and likely shitty kernel patches back and forth to try to maintain some kind of compatibility in the long run at this rate.
How much Linux does Huawei use? Especially with they Huawei Harmony next OS?

Please, Log in or Register to view URLs content!
 
Top