I'm not very happy with the do {} while() statement in C

[Ras]

but I don't think the x86-64 instruction set is a good example of how to encode instructions efficiently.

Yeah, you're probably right on that one. That compression happened more or less by accident simply because the most frequent instructions were added first.

[Ras]

Then why does the open source RISC V not resemble the Intel model?

Because it's originally an academic design from the ivory tower. The main advantage is that the ISA is free so that any vendor can make its own proprietary lock-in, which is why companies like Samsung are interested.

But right now, the things that you can actually buy with RISC-V are both ridiculously overpriced and totally disappointing at the same time.

[bob]

Only question is, who wants to do that? No speed savings to fetch less than an 8 byte value, a penalty in fact... Causes lots of overhead on the network which is big-endian in data transmission (hence the hton functions in the network library...

I found a use case for this in my current project. Certainly it's not about speed.

Lots of overhead? You can't be possibly serious... bswap is fast as mov and this only covers packet header, not the data you send.
Considering what you have to do on the CPU part to just send a packet, it boils down to nothing, certainly not anything you could even measure.

"lots of overhead". Every one of those has a procedure call and return. That's the problem I mentioned, the htonX functions... On a big endian architecture those functions are empty and optimized away completely.

[bob]

saddling the development community with a scrawny architecture basically forever.

Well, no. The last true x86 architecture was the 486. After that, we still have the external x86 instruction set, but not the architecture; internally, modern x86 CPUs are something entirely different. And nobody cares for the external instruction set. Already 10 years ago, the actual x86 related part of the CPU's die was neglectable.

What this variable length CISC ISA does is actually a sort of compression, and since CPU speed has increased way more than memory speed, this is even a good thing, because it's a better use of the CPU caches.

First, the original pentium was still X86 through and through. The pentium-pro was the first shift. If you think about it, today we have what one might call either Pascal P-code or Java byte-code. The X86 ISA is the byte-code equivalent. Then the JVM is the internal CPU after the instructions have been fetched, converted to micro-ops, and stuck in the reorder buffer. The micro-code processor executes something that looks remarkably like the older RISC machines, loads, stores, everything else only uses registers... Clever design that lets the old crap ISA run on any sort of internal core they choose to design. but the X86 ISA is a crap ISA.

Ack what a design however. A processor within a processor which admits the original processor ISA was pretty crappy. The current internal ISA is actually pretty clever.

[bob]

Little endian is a retarded design that came due to backward compatibility with the original 8 bit architecture. Many machines have done it right (big endian).

Little endian has one important property, fetching smaller integer from the same address. This is the reason why BE sucks and why LE is actually useful.

I assume you mean either uints (since the sign bit is not exactly useful on a piece of a long negative int) or else you probably didn't mean "short ints" at all and instead meant something like LSBs (least significant bits). I've never seen where that is particularly useful, offering something I can't do on a traditional big-endian architecture.

The old Rybka investigation offers a key objection. Try searching for a known hex constant in a memory dump. Easy in big-endian, not nearly so easy in little-endian. IE I'd like to see the constant 257 look like "0000000000000101" (hex) in 64 bit integer format. Not like it was bitten off, chewed up, and sneezed back into memory.

Its ONLY claim to fame was that Intel could use the 8 bit form of an instruction (mov a, mem), or a 16 bit form (mov ax, mem) and the 8 bit form was just the first of two cycles, reusing cpu resources. IE 8 bit instruction exited after one iteration, 16 bit after two iterations... clever design, horrible architecture.

[Ras]

"lots of overhead". Every one of those has a procedure call and return.

Only with a lousy compiler because these function calls should be optimised away. Just like calls to memcpy for getting around pointer aliasing are eliminated for basic data types.

[mar]

Only with a lousy compiler because these function calls should be optimised away. Just like calls to memcpy for getting around pointer aliasing are eliminated for basic data types.

In Linux htonx are macros that map to compiler intrinsics so no performance overhead whatsoever, so not a single valid argument yet as to why BE is superior.

that it's "readable for humans" in memory? that's beyond desperate

msc/gcc/clang generat inline code for memcpy when length is a compile time constant => very useful if you're fetching from unaligned pointer on archs where this would otherwise segfault.
the only exception is (used to be ~2 years ago?) intel compiler.

[AlvaroBegue]

Has anybody here read Gulliver's Travels? The names big-endian and little-endian come from that novel, where the inhabitants of Lilliput are bitterly divided over how eggs should be broken (at the big end of the egg or at the little end). I don't know whose idea it was to name the byte-order conventions, but the names are brilliant. The whole point is that it doesn't really matter, but people will argue strongly about it forever.

[mar]

I assume you mean either uints (since the sign bit is not exactly useful on a piece of a long negative int) or else you probably didn't mean "short ints" at all and instead meant something like LSBs (least significant bits). I've never seen where that is particularly useful, offering something I can't do on a traditional big-endian architecture.

I mean simply that they share the same address.

even if I'd like to "fix" my program and make it portable wrt to endianness, it's hard to find a virtual machine capable of running say powerPC with linux distro including recent devel tools (like C++11)

I tried quemu + powerPC in the past and some ancient debian distro, it ran but like 2 orders of magnitude slower than what I'd consider usable.
Plus no recent C++ compiler for me.

so despite the fact that BE is so awesome, nobody seems to be using it these days, even Android/iOS on ARM (which should support LE or BE in hardware) is configured to be LE.
obviously because it adds lots of overhead when working with the net

The old Rybka investigation offers a key objection. Try searching for a known hex constant in a memory dump. Easy in big-endian, not nearly so easy in little-endian. IE I'd like to see the constant 257 look like "0000000000000101" (hex) in 64 bit integer format. Not like it was bitten off, chewed up, and sneezed back into memory.

At least you have a sense of humor

Its ONLY claim to fame was that Intel could use the 8 bit form of an instruction (mov a, mem), or a 16 bit form (mov ax, mem) and the 8 bit form was just the first of two cycles, reusing cpu resources. IE 8 bit instruction exited after one iteration, 16 bit after two iterations... clever design, horrible architecture.

sorry, I don't follow.

while I don't dislike flamewars, this is already getting a bit too off-topic even for me

@Alvaro: very nice, I didn't know that

[syzygy]

Has anybody here read Gulliver's Travels?

Then you'll also know where Yahoo comes from.

The names big-endian and little-endian come from that novel, where the inhabitants of Lilliput are bitterly divided over how eggs should be broken (at the big end of the egg or at the little end). I don't know whose idea it was to name the byte-order conventions, but the names are brilliant. The whole point is that it doesn't really matter, but people will argue strongly about it forever.

It comes from ON HOLY WARS AND A PLEA FOR PEACE by Danny Cohen.

Other Holy Wars worth fighting for are Vi vs Emacs, Linux vs Windows, Gnome vs KDE, C64 vs Spectrum, C64 vs Atari, Amiga vs Mac.