News for hackers. Stuff that matters.
Re:GCC-Rust: Rust frontend for GCC by onei on Sunday December 08, 2019 @03:40AM (#21734942)
In theory, both GCC and LLVM take a front-end (in this case rust) and compile it down to an intermediate representation (IR). There will likely be some differences between the output from a front-end, but after successive optimisations have been applied this will likely disappear. By the time you get to generating assembly, you can't really tell the difference anymore so the semantics of the original language don't make an impact.
Re:GCC-Rust: Rust frontend for GCC by saagarjha on Sunday December 08, 2019 @03:49AM (#21734966)
I'm sure there are a number of "reasonable" assumptions that aren't true–probably things like the number of bits in a byte, or the size of a particular integral type, or support for a particular platform behavior.
Re:GCC-Rust: Rust frontend for GCC by sanxiyn on Sunday December 08, 2019 @03:51AM (#21734975)
https://gankra.github.io/blah/rust-layouts-and-abis/ lists assumptions. As you suspected, one assumption is 8-bit bytes.
Re:GCC-Rust: Rust frontend for GCC by Yoric on Sunday December 08, 2019 @07:09AM (#21735505)
Wait, isn't this the definition of a byte?
Re:GCC-Rust: Rust frontend for GCC by sanxiyn on Sunday December 08, 2019 @07:24AM (#21735556)
It isn't in Texas Instruments TMS320. I will quote from http://processors.wiki.ti.com/index.php/C89_Support_in_TI_Co...

> The C standard uses the term byte to mean the minimum addressable unit in the implementation, which is char, which means a byte on these targets is 16 bits. This is in conflict with the widespread use of byte to mean 8 bits exactly. This is an unfortunate disagreement between C terminology and widespread industry terminology that TI can't do anything about.

Re:GCC-Rust: Rust frontend for GCC by hyperman1 on Sunday December 08, 2019 @07:51AM (#21735641)
Absolutely not. A byte is the smallest block of memory with an address. E.g you can't take the address of 7 combined bits on x86 but you can for 8.

In the past, architectures differed wildly in number of bits per byte, e.g 36 for the machine where the Pascal language was created.

Today, the industry mostly standardized on 8 bits per byte, but see e.g the PIC architecture for an example relevant today with a different choice: 8 bit bytes for data, but 10 bit bytes for instructions.

https://en.m.wikipedia.org/wiki/PIC_microcontrollers

Re:GCC-Rust: Rust frontend for GCC by cwzwarich on Sunday December 08, 2019 @09:37AM (#21736057)
> A byte is the smallest block of memory with an address. E.g you can't take the address of 7 combined bits on x86 but you can for 8.

I think that's an anachronistic/incorrect usage. A lot of machines (including several with 36-bit words that you mentioned) supported larger basic addressable units of memory, but didn't call these larger units "bytes", and distinguished between "bytes" and "words". In fact, one of the elements of the early RISC philosophy was that CPU support for byte accesses (as opposed to word accesses) was extraneous, based on statistics gathered from real programs. Early MIPS/Alpha/etc. machines did not support byte addressing, but the people using them still called 8 bits a byte.

Re:GCC-Rust: Rust frontend for GCC by justincormack on Sunday December 08, 2019 @02:39PM (#21737761)
Arguably the first Alphas could have had a C compiler with 64 bit bytes but that would have made porting hard. Even then they were forced to add byte operations pretty early on.
Re:GCC-Rust: Rust frontend for GCC by detaro on Sunday December 08, 2019 @07:26AM (#21735561)
Byte is also often defined as the smallest addressable unit in a computer. Which nowadays most commonly is 8 bit, to the point where you can generally assume it, but this was different in the past (6 and 9 bit being especially common alternatives) and is still in some niches like DSPs, which sometimes only can work on wider types. But at least those then are typically powers of two, which makes it easier for many tools.
Re:GCC-Rust: Rust frontend for GCC by int_19h on Sunday December 08, 2019 @04:57AM (#21735150)
There are architectures on which sizeof(char)==sizeof(short)==sizeof(int) in C implementations, because it's the only way to produce efficient code.