-
Once again... Linus T. rejected the risc-v patches, judging them to be "garbage" ....
Too rush? well ...no doubt about.
He was partly right, in my opinion, because it wasn't clear which part of the code was RISC-V-only (arch-dependent) and which part was generic.
That's precisely what he also doesn't like with ARM and MIPS too...
It just should have been more closely reviewed by Palmer [1] before he put his stamp of approval on it, and especially not submitted in a huge chunk just before the end of a release window. Hold off a few days until the start of the process for the next release and it would have been business as usual and not in the news.
Oh well, over on /r/riscv that story has been read 93k times in 10 days and the sub only has 27k members [2], which actually has increased by a net 790 (3%) in the last 30 days, possibly as a result of the "bad" publicity.
There are FAR MORE people who haven't heard of RISC-V at all than who think bad things about it.
[1] who used to be my boss at SiFive and was kind enough to loan me his 2nd car when I was in the process of moving to the US (a V6 Mondeo with Jaaaaaaaag styling)
[2] most stories get read 3k-10k times. My "How relevant will RISC-V chips the speed of 5-year old Apple M1 be?" discussion posted just before I went to bed last night has been read 13k times in the first 13 hours.
-
Yeah, that was probably "rushed", especially knowing the "guidelines" for the Linux kernel. With that said, technically speaking, Linus reacted to things that were pretty close to opinions rather than anything "garbage". That term was uncalled for. The submissions did not really follow the usual code style for Linux, but they were not garbage.
-
Linus, as he often is, is ignorant outside of his narrow area.
The possibility for big-endian RISC-V was designed-in almost from the beginning, being included in v2.0 of the Unprivileged Architecture in May 2014, 2 1/2 years before the first RISC-V product went on sale. The ratified ISA, published in December 2019, includes provision for S and U modes to run in different endianess (bi-endian), if desired.
The MIPS I8500 core supports bi-endian operation.
https://mips.com/products/hardware/i8500/
https://mips.com/products/software/i8500-sdk/
- 3-Wide, 9-stage, in-order pipeline with 1-, 2-, 4-way SMT ("Hyperthreading" in Intel talk)
- Supports big-endian and little-endian
This, obviously, is a commercial product, not some "university student experiment".
-
Although the feature was never used, even the Sony MIPS R3000 used in Playstation1 supports bi-endian operation, and it's able to boot BE or LE firmware!
(Ok, in this case is ... once set, you cannot change, you have to stay with it)
Modern POWER CPUs also support bi-endian operation!
Ah, Linus ... -
Also what was the point? That conversion from/to p_uint32_t to p_uint8_t (C pointer) is "free" on LE but costs an offset of 3 on BE?
Is that so really complex to manage to avoid bugs?
That rants makes no sense -
Also what was the point? That conversion from/to p_uint32_t to p_uint8_t (C pointer) is "free" on LE but costs an offset of 3 on BE?
Converting from uint32_t to uint8_t by writing to and reading from RAM instead of sensibly doing a zero-extension instruction in a register (which works the same no matter what the endianess) is far from "free".
In fact it can be much more expensive than you'd expect because many µarches stall if you try to read from a memory address that is still in the write buffer, and that is all the more likely if there is an access size or alignment mismatch (as there is here).
Even if there is no dedicated zero-extend instruction doing ((my_uint32_t << 24) >> 24) is only two cycles [1] on any post 1985 CPU (68020, 80386, all known RISC), and has the added benefit that by adjusting the constant you can zero extend (or sign extend for int32_t) from any desired bit position.
[1] or at least the same as two back-to-back adds, if they take more than 1 cycle
-
Yes Linus has strong opinions and tends to voice them as though the contradicting opinion was stupid and garbage. As much as I respect his work and don't mind people being upfront, that's still annoying at times.
Yes, bi-endian CPUs are relatively rare but not stupid or irrelevant. Yes, it was in the RISC-V specs relatively early on. If Linus doesn't want that in the Linux kernel, then it basically means RISC-V support for Linux is dead. And with that attitude, who knows what will happen when RISC-V comes up with new extensions that Linus deems garbage.
Will CHERI ever end up in Linux?
https://github.com/cheri-linux
-
If Linus doesn't want that in the Linux kernel, then it basically means RISC-V support for Linux is dead. And with that attitude, who knows what will happen when RISC-V comes up with new extensions that Linus deems garbage.
I don't see why it should be. It can simply *not* support the Cores that are Big Endian only. Shouldn't they be the vast minority of the chips? -
That rants makes no sense
You forget: Linus' main task is to keep the Linux kernel maintainable by mere humans, himself being just one of us.
That means he has to push hard on everything he thinks might make maintenance in the long run even a tiny little bit harder, unless it is really, really worth it.
The key paragraph was the one just after the one you highlighted.
Note that I am not saying that Linus is right. Or wrong. I'm only saying that his rant makes sense from his point of view, as the project lead. For the developers and end users who want big-endian byte order hardware support, not so much. But this rant is nothing final, and only means a good, valid explanation of exactly how and why this is desirable/required.
(I post this because I've found that when I require such explanations from myself, I end up understanding better what I am doing, and how my mental image of it differs from the actual reality. You also see this in how I always explain the reasoning behind my suggestions instead of just showing my suggestion and letting it stand on its own; it has become part of my design approach. Granted, I'd freeze if I received such a rant, especially publicly! But, when not being in the firing line myself, I don't see it as a "No!", but more as "No, unless you explain exactly why", with the focus on that missing explanation; with that explanation in my experience being a very necessary and important part of the design documentation — which for the Linux kernel, is basically the Linux Kernel Mailing List and subsystem lists.) -
Also what was the point? That conversion from/to p_uint32_t to p_uint8_t (C pointer) is "free" on LE but costs an offset of 3 on BE?
Converting from uint32_t to uint8_t by writing to and reading from RAM instead of sensibly doing a zero-extension instruction in a register (which works the same no matter what the endianess) is far from "free".
In fact it can be much more expensive than you'd expect because many µarches stall if you try to read from a memory address that is still in the write buffer, and that is all the more likely if there is an access size or alignment mismatch (as there is here).
Even if there is no dedicated zero-extend instruction doing ((my_uint32_t << 24) >> 24) is only two cycles [1] on any post 1985 CPU (68020, 80386, all known RISC), and has the added benefit that by adjusting the constant you can zero extend (or sign extend for int32_t) from any desired bit position.
[1] or at least the same as two back-to-back adds, if they take more than 1 cycle
Good point, I was thinking from the myC machine layer perspective, that is, what my myC compiler does when it needs to handle pointer conversions.
Unlike traditional C, where endianess isn't a type property but something to be managed manually (usually with macros/ inline functions), in myC endianess is a type property, managed directly by the language.
So you can easily say: in this struct, this field has endianess BE, and the compiler will automatically instantiate what's needed to adapt the endianess of that specific field to the size of the operation requested and the CPU's endianess, which is itself a property of the project.
In short, once you've declared endianess, you don't have to worry about the details; the compiler takes care of it!
-
but... my machine layer is not smart enough, as you pointed out, there's a better way to do it.
-
Having big-endian and little-endian data types is an interesting idea.
A CPU can similarly have BE/LE load/store instructions instead of having endianness either set in stone or as a global setting.
So for instance, instead of just lw, sw, you can have lw.le, lw.be, sw.le, sw.be.
Whether it's really useful in practice will all depend on the kind of applications it's dealing with. BE is now a rare beast and mostly used for networking code and similar (for instance, peripherals with an I2C or SPI bus frequently use BE words as well). In both cases, the main rationale is the fact bits are transmitted MSB first - and then, if one considers the bit stream rather than how it's organized in "words", it only makes sense to use BE, because it preserves bit ordering. -
yeah, I have BE on
- m68k, m683xx, CPU32, coldfire-v1, ... , which is BE-only
- MIPS4 (SGI/MIPS), which is BE-only
- MIPS5 (SGI/MIPS), which is BE-only
- Apple PPC32, PowerMac G4, which is BE-only
- Apple PPC64, PowerMac G5, which is BE-only
- IBM/AMCC PPC4xx, which is BE-only (still used in avionics)
- HP RISC HPPA-v1 (32bit), which is BE-only (I don't directly support it, I have no hardware, but the userland I support is 32bit)
- HP RISC HPPA-v2 (64bit), which is BE-only (I directly support it, 64 bit kernel, but the userland I support is 32bit)
- IBM POWER8 and 9, which is LE/BE, but I only support BE kernel and userland
except IBM POWER, all the other archs do no more have any commercial support ... -
Quote from: SiliconWizard
Having big-endian and little-endian data types is an interesting idea.
A CPU can similarly have BE/LE load/store instructions instead of having endianness either set in stone or as a global setting.
The reason I added it to myC was to support mac-parts in all my bootloaders
If you recall, I talked about how Allwinner decided to set the endianess of its SoCs to LE-only and how FriendlyArm & Co. decided to support uboot.
When I talked about the Neo and NeoAir board what I didn't mention, however, was that they REMOVED all endianess support for anything they deemed unnecessary, including mac-parts support!
Why? Because they thought MBR and GUID Partition Table (GPT) were sufficient partitioning systems.- MBR is strongly LE because it was born on x86, which is only LE
- GPT... I've never understood why it has to be LE, but really, if you have a LE SoC... GPT is LE and has no other support
- mac-part was born on PowerMacs, which are BE... so they removed all the code!
Supporting mac-parts' endianess wasn't particularly complicated, as they're almost all uint32 and uint16, but then I also started writing the rb532 network driver from scratch, and here we have a problem: where the (MIPS32R") CPU is LE, many registers in the network SoC subgroup are BE... and it's a mix of uint8, uint16, and uint32...
So I kept that feature of the language because it really made the difference between risking bugs by forgetting to mention a macro that fixes endianess (like with C99 in uboot), and compiling the structs specifying the endianess and size of each field, and then letting the myC compiler do all the work!Quote from: SiliconWizardSo for instance, instead of just lw, sw, you can have lw.le, lw.be, sw.le, sw.be.
The R18K MIPS5++ SoC actually have a full bi-endian load/store implementation.
Nice tricks!
I haven't used it yet in myC's machine layer because I don't know if this feature is also present in other ISAs...
I don't know how much it's worth.
Sure I could add this feature to the ISA of my softcore toy, but the MIPS5++ is a completely dead and abandoned ISA prototype ...
... so
-
Having big-endian and little-endian data types is an interesting idea.
It is technically what the Linux kernel-userspace API has tried to specify for ages, by defining types __le16, __be16, __le32, __be32, __le64, and __be64, which by themselves are only allowed in load, store, binary, and comparison operators (verified by sparse and its bitwise attribute). The intent is you "convert" the type to a native byte order first before any arithmetic and function parameter use, just like you do in POSIX C using htons(), ntohs(), htonl(), and ntohl() for conversion between network byte order fields and host byte order as used in the internet protocol (IP) support for Berkeley sockets network interfaces).
Don't forget, little-endian and big-endian are technically not the only byte orders we have used, either. PDP-11, anyone? For 32-bit values on 8-bit bytes, we have four possible byte orders. For 64-bit, eight. And those are just the symmetric ones, excluding ridiculous asymmetric orderings like 1243 or 2134.
If you've ever written C networking code, I'm pretty sure you can see why having the compiler track and work out the byte order details for IP addresses and ports in the datagram headers and correspondingly, the POSIX C Internet Protocol socket API, would yield much more maintainable and human-readable code.
Another extremely similar details is Named Address Spaces. GCC supports them in C, but not in C++. Clang supports them in both C and C++. x86-64 can use it (although its most useful for kernel stuff and similar that straddles different virtual address domains), but for most architectures it is just added complexity that seems unjustified. For AVRs without unified address spaces, it would have made a huge positive difference, big benefit, but the lack of it in GCC C++ explains all the odd workarounds Arduino environment ended up with, like copying even string literals to RAM instead of using them directly from Flash (like you can trivially do if using GNU C and not GNU C++). -
So I kept that feature of the language because it really made the difference between risking bugs by forgetting to mention a macro that fixes endianess (like with C99 in uboot), and compiling the structs specifying the endianess and size of each field, and then letting the myC compiler do all the work!
C++ circa 1989 (or 1991 if you want to template it) solved this no problems, so with a few simple definitions you could write code like...Code: [Select]struct foo {
LE_uint64_t x;
BE_uint64_t y;
};
void bar(foo &p){
p.y = p.y + p.x;
}
... and it will just Do The Right Thing.
amd64Code: [Select]bar(foo&):
mov rax, QWORD PTR [rdi+8]
bswap rax
add rax, QWORD PTR [rdi]
bswap rax
mov QWORD PTR [rdi+8], rax
ret
riscv64Code: [Select]bar(foo&):
ld a5,8(a0)
rev8 a5,a5
ld a4,0(a0)
add a5,a5,a4
rev8 a5,a5
sd a5,8(a0)
ret
arm64Code: [Select]bar(foo&):
ldp x2, x1, [x0]
rev x1, x1
add x1, x1, x2
rev x1, x1
str x1, [x0, 8]
ret
power64Code: [Select]bar(foo&):
.quad .L.bar(foo&),.TOC.@tocbase,0
.L.bar(foo&):
li 9,4
lwbrx 8,9,3
lwbrx 10,0,3
rldimi 10,8,32,0
ld 9,8(3)
add 9,9,10
std 9,8(3)
blr
The three LE machines have to swap y both loading it and storing it. BE Power64 only has to swap x but it seems there is only a 32 bit "load with byte swap" instruction so it has to do two of them and then combine the two halves with a bit field insert.
https://godbolt.org/z/4oz5Mve1c
-
So I kept that feature of the language because it really made the difference between risking bugs by forgetting to mention a macro that fixes endianess (like with C99 in uboot), and compiling the structs specifying the endianess and size of each field, and then letting the myC compiler do all the work!
C++ circa 1989 (or 1991 if you want to template it) solved this no problems, so with a few simple definitions you could write code like...
I never programmed in C++, only in C/89 and C/99, so I didn't know there was a similar idea ...
myC is 90% C/89, but with the struct fields taken from C/99(2) ...
After doing crazy things(1), which I still don't know if they are right or wrong ... usefull or useless ...
... well at least now I know I've done something good!
because others have already done it and proven to be correct and useful!
(1) struct-type entanglement, crazy idea? (myC), see here
(2)Code: [Select]typedef struct(this is only correct with C/99)
{
uint8_t id;
uint32_t magic;
} my_t;
my_t my=
{
/* it is NOT necessary to strictly respect the order of the fields */
.magic=0xdeadcafe,
.id=55
};Code: [Select]my_t my=(this is correct with C/89 and C/99)
{
/* it is necessary to strictly respect the order of the fields */
55,
0xdeadcafe
}; -
Well with any "object-oriented" language, you can do this and pretty much anything with operators based on a given type. There's nothing fancy about it, unless you find OO fancy, which it probably was 50 years ago.
-
Well with any "object-oriented" language, you can do this and pretty much anything with operators based on a given type. There's nothing fancy about it, unless you find OO fancy, which it probably was 50 years ago.
Notationally, yes, but most OO languages are going to store one of those fields as an integer and one as a pointer to a heap object, with attendant boxing and unboxing memory size and code size and speed penalties.
It even took quite some time to get C++ compilers to have no abstraction overhead. If you actually wrote this with a 1989 C++ compiler you wouldn't get as good code as I showed. It took quite a bit of pushing from Alex Stepanov to get C++ compiler vendors to improve their products so that his "STL" worked as intended. Metrowerks CodeWarrior was the first IIRC and their "PowerPlant" application framework heavily used the latest C++ features.
-
And more generally, GCC and Clang have really benefited from the friendly competition, having somewhat different design decisions and seeing how they affect the implementations, demolishing the incorrect assumptions of what is feasible/possible, and what is just an artefact of the chosen internal representation and implementation approach. Even the ISO C23 standard (I suggest draft N3220 that is after the standard but only differs by one footnote) shows how C is benefiting from porting useful concepts from existing implementations (including C++), now that the committee is again focusing on the standard and not the needs of one specific vendor.
-
How did i miss this? Apparently there is a new RISC-V Mainboard for the framework 13
https://deepcomputing.io/product/dc-roma-risc-v-ai-pc/
But i think it's using the same SOC as before?
Repository says "soon" for device files https://github.com/DC-DeepComputing/Framework -
How did i miss this? Apparently there is a new RISC-V Mainboard for the framework 13
https://deepcomputing.io/product/dc-roma-risc-v-ai-pc/
Well, it's not available quite yet.QuoteBut i think it's using the same SOC as before?
What? Of course not.
The original board uses a StarFive JH7110 SoC with 4x U74 cores (similar to Arm A55), the "AI PC" uses an ESWIN EIC7702X with 8x P550 cores (similar to Arm A72).
-
Ah! I've found different threads, some dated back from may. It was a bit confusing to understand which one were speaking about what, and DC's website is just as confusing.
I really want to replace the old macbook, but i just upgraded the main PC so i will wait a few more months for that. Maybe this board will get debian support in the meantime, maybe something more interesting (and worth waiting a few more months) will appear -
I really want to replace the old macbook, but i just upgraded the main PC so i will wait a few more months for that. Maybe this board will get debian support in the meantime, maybe something more interesting (and worth waiting a few more months) will appear
If your MacBook is a G3 or G4 then this is a definite upgrade, or a Core 2 Duo if you're doing things that can use 8 cores rather than 1 or 2. Or an original MacBook Air, which was Core 2 Duo at 1.6 GHz for about 5 seconds, then 1.2 GHz for 30 seconds, then 800 MHz forever.
Next year will see chips from Tenstorrent similar to the Apple M1 (and designed by one of the M1's main architects), but probably at around 2.0 to 2.4 GHz rather than Apple's 3.4 GHz, so a little bit slower single core, but again the RISC-V chips will have more cores than the base level M1. They've said they want to see those chips in as many hands as possible, explicitly including laptops, not only corporate servers.
-
I really want to replace the old macbook, but i just upgraded the main PC so i will wait a few more months for that. Maybe this board will get debian support in the meantime, maybe something more interesting (and worth waiting a few more months) will appear
If your MacBook is a G3 or G4 then this is a definite upgrade, or a Core 2 Duo if you're doing things that can use 8 cores rather than 1 or 2. Or an original MacBook Air, which was Core 2 Duo at 1.6 GHz for about 5 seconds, then 1.2 GHz for 30 seconds, then 800 MHz forever.
Next year will see chips from Tenstorrent similar to the Apple M1 (and designed by one of the M1's main architects), but probably at around 2.0 to 2.4 GHz rather than Apple's 3.4 GHz, so a little bit slower single core, but again the RISC-V chips will have more cores than the base level M1. They've said they want to see those chips in as many hands as possible, explicitly including laptops, not only corporate servers.
No, it's the Mid 2012 with the series 3 i5.. I don't really need a powerful laptop anymore, i've got a new desktop with brand new hardware for gaming and work, and i've quit playing music for the time being (also i had transitioned back to physical instruments only, anyway)
I want it to be non-x86, just because, and it would be my little part to make the alternatives grow.
But as i said, a few more months before buying anything else, let's see what happens in the meantime (i did remember you mentioning already the tenstorrent)