Enlightened
-
@masonwheeler Yes, and C aficionados will whine about how it's impossible to control memory allocation in Java. Doesn't mean it's actually a valid complaint.
-
@gąska said in Enlightened:
From now on, I'm never going to assume anything is easily googlable even if it is for me....
A safe assumption, though we are a pretty tough crowd. :)
@gąska said in Enlightened:
Also, I'm never going to assume that a common knowledge among C programmers is common knowledge among people discussing C.
FWIW, this is also a term I hadn't heard before despite my experience coding C and C++. I have dealt with component parts like setting calling conventions, dealing with the .NET Marshaler, and being aware of ABI issues on various platforms, just not this particular combined term for it.
-
@parody said in Enlightened:
FWIW, this is also a term I hadn't heard before despite my experience coding C and C++.
Nor had I. I've heard FLI — Foreign Language Interface — but never FFI.
-
-
@zecc well, I did also have J2ME, if it helps.
-
@hardwaregeek said in Enlightened:
I assumed from the fact that @dkf asked about it that there wasn't such an explicit declaration.
Not that I noticed. I could see that it used some variation on placement new to put a structure in a specific location in memory (reasonable) and that the writes to the locations were function-wrapped, but not the fact that writes were actually volatile.
I looked up what might be the implementation of the code that does the writes…
syscall/src/io/io.rs at 7c805d2a289ec19bf505256eb90395913d9f50b9 · redox-os/syscall
Mirror of https://gitlab.redox-os.org/redox-os/syscall - redox-os/syscall
…and I still can't see where the writes are enforced.
-
@dkf you're looking at the wrong file.
Iois a trait and doesn't implementreadandwriteitself. Look atpio.rsandmmio.rs.
-
@dkf said in Enlightened:
@pie_flavor said in Enlightened:
Rust.
Does it support fixed-point arithmetic yet?
Well, still a bit worse than C++, but that's way better than C (and most other languages for that matter, because they tend not to have integeral generic parameters either).
-
@bulb said in Enlightened:
Well, still a bit worse than C++,
C++ supports fixed-point arithmetic?
Sure, the class mechanism / operator overloading allows you to write your own fixed-point type that behaves just like a built-in one would. That's good enough, IMO, but as far as I know it doesn't come with such a type out of the box.
-
@topspin said in Enlightened:
C++ supports fixed-point arithmetic?
It's not part of standard C++. However, some compilers do, notably builds of gcc for embedded use and also armcc (ARM's commercial compiler). In theory, you could do fixed point math as an ordinary library instead, but things get complicated once you're not just doing simple operations and the quality of the resulting code isn't clear (and is utterly critical in this application area). Support for the sorts of interesting functions that you find in
<cmath>is usually lacking; we have our own C libraries for doing that. (Those libraries are classic examples of why magical constants are not universally bad, and why algorithms are not automatically correct just because their types are correct…)
-
@pie_flavor said in Enlightened:
@masonwheeler Yes, and C aficionados will whine about how it's impossible to control memory allocation in Java. Doesn't mean it's actually a valid complaint.
It's quite possible to control memory allocation in Java. What it's not possible to control is memory deallocation, and that's very much a valid complaint. Microsoft Research has been working on a solution to that problem on the CLR, which I really hope ends up making it into production...
-
@dkf said in Enlightened:
The value proposition of Rust simply isn't very strong in this area; the problems that language solves aren't particularly pressing concerns in embedded systems development.
Actually it is quite strong. The borrow checker can also be used for verifying synchronization and that is useful for checking access to memory-mapped I/O ports. See http://blog.japaric.io/brave-new-io/.
Hardware folks are a conservative bunch. It will take them some years to realize the benefits of Rust—and update the verification tools they have for it, because while the compiler catches many issues itself, it does not eliminate the need for all the tools.
-
@bulb said in Enlightened:
Hardware folks are a conservative bunch. It will take them some years to realize the benefits of Rust
The biggest issue for us is simply compiler support. You can get a C compiler for anything. Not so for Rust, and it never will be, because some parts of our industry are stuck in the 1970's...
-
@mott555 the thing is, Rust is the second programming language in the history of programming languages that has any chance at all to compete with C in embedded space (the first being C++), and the first one that brings enough improvements over C for embedded programming that it might actually win the fight. I'm confident that at the very least, there will eventually be Rust compiler for every platform that has C++ compiler.
Some cool resources about what you can currently do with Rust in embedded can be found here:
GitHub - rust-embedded/awesome-embedded-rust: Curated list of resources for Embedded and Low-level development in the Rust programming language
Curated list of resources for Embedded and Low-level development in the Rust programming language - rust-embedded/awesome-embedded-rust
-
@gąska Maybe. I have a hard time believing Rust will ever be supported on obscurities like CentOS 3 with a custom real-time kernel though. (Personally I don't think we should be supporting OS's that old, but apparently there's money in it...)
-
-
@timebandit We've had better luck pushing customers off Windows XP than from ancient CentOS versions.
-
@gordonjcp said in Enlightened:
@pie_flavor Okay, so in Rust I can just declare a big chunk of memory and poke about in it without the compiler trying to interfere?
Of course you can (and always could; Rust is designed so you can write everything in it starting with bare metal).
But the point is you can do more. You can define an abstraction for the chunk of memory that defines how you want to poke it and then the compiler will check that you only poke it the way you said you want, which improves maintainability code significantly as you can trace down which parts of the code poke it easily when you want to change it.
-
-
@bulb said in Enlightened:
You can define an abstraction for the chunk of memory that defines how you want to poke it and then the compiler will check that you only poke it the way you said you want
-
@dkf said in Enlightened:
In theory, you could do fixed point math as an ordinary library instead, but things get complicated once you're not just doing simple operations and the quality of the resulting code isn't clear
Can you elaborate?
Fixed point seems much simpler to get correct than IEEE-754. Why wouldn't a library work well for that?
-
@mott555 said in Enlightened:
The biggest issue for us is simply compiler support. You can get a C compiler for anything. Not so for Rust, and it never will be, because some parts of our industry are stuck in the 1970's...
Why do all these
embedded vendors even ship their own C compiler?
Apart from legacy code bases, is there any reason to ship more than the codegen back-end for LLVM / GIMPLE (or whatever gcc uses)? The code-gen really shouldn't need to care if the input was C or Rust or whatever, and you don't need to deal with front-end bugs where your compiler doesn't get some C features correct.
-
@masonwheeler said in Enlightened:
@pie_flavor said in Enlightened:
@masonwheeler Yes, and C aficionados will whine about how it's impossible to control memory allocation in Java. Doesn't mean it's actually a valid complaint.
It's quite possible to control memory allocation in Java. What it's not possible to control is memory deallocation, and that's very much a valid complaint. Microsoft Research has been working on a solution to that problem on the CLR, which I really hope ends up making it into production...
You have missed the point.
-
@bulb said in Enlightened:
The ports are wrapped in the Pio and Mmio descriptors and those are using suitable inline assembly.
Strictly, the mmio stuff doesn't need to (as all that's required is making the read or write of the address impossible to optimise out or reorder past another volatile memory op) and indeed it doesn't. Pio isn't portable; the concepts it works with don't apply to all CPUs (specifically not ARMs) at all, so even the fact that it needs assembly to do isn't the biggest stumbling block to universal use. Not that that's a criticism in the slightest; everything to do with devices is non-portable (blame hardware makers for the bizarre array of ways they do things).
Anyway, to go back to the earlier point, there's plenty of
unsafecode blocks in there. It's just in the drivers library; I found that the majority of a quick sample (a driver for a network interface) was unsafe. I imagine I'll find similar trickiness in the interrupt system (if I can find where that actually is) but we're getting into
territory here.
-
-
@topspin said in Enlightened:
@bulb said in Enlightened:
Well, still a bit worse than C++,
C++ supports fixed-point arithmetic?
Sure, the class mechanism / operator overloading allows you to write your own fixed-point type that behaves just like a built-in one would. That's good enough, IMO, but as far as I know it doesn't come with such a type out of the box.I use quite a few languages, but none of them has fixed-point type built in. Which one you had in mind?
-
@bulb We must be misunderstanding each other, since my point was exactly that it doesn't have a fixed-point type.
-
Why does every discussion of EFL turn into this minutae about C. Every fucking time.
-
@blakeyrat Does a C pointer have Buddha-nature?
-
@blakeyrat said in Enlightened:
Why does every discussion of EFL turn into this minutae about C. Every fucking time.
Because every discussion about C turns into discussion about C.
-
@mott555 said in Enlightened:
@bulb said in Enlightened:
Hardware folks are a conservative bunch. It will take them some years to realize the benefits of Rust
The biggest issue for us is simply compiler support. You can get a C compiler for anything. Not so for Rust, and it never will be, because some parts of our industry are stuck in the 1970's...
Rust uses the LLVM backend and it covers a lot. But for the cases it does not, let me also introduce mrustc, the rust-to-c translator.
@mott555 said in Enlightened:
I have a hard time believing Rust will ever be supported on obscurities like CentOS 3 with a custom real-time kernel though.
You are calling that obscure? It's a common CPU type, uses ELF object format and has a standard C library. If the C library is very special, you may need to rebuild the Rust standard library, but beyond that it should probably target it out of the box (the compiler may not be running there, but you shouldn't need to compile there, just run the resulting binary, no?).
Under “obscure” I would imagine 8-bit and 16-bit microcontrollers. Those may not be supported, because LLVM is generally written with at least 32-bits in mind.
@mott555 said in Enlightened:
@timebandit We've had better luck pushing customers off Windows XP than from ancient CentOS versions.
CentOS 3 is not what I call ancient. GNU/Linux should be essentially backward compatible back to Linux 2.0 (1996) and the ELF transition, which I remember was complete by 1998.
-
@topspin said in Enlightened:
@bulb We must be misunderstanding each other, since my point was exactly that it doesn't have a fixed-point type.
But that sounded like you have a language that does. So do you? Or are you just asking for a killer feature nobody has so far? In the later case I would strongly argue the power to add it as a library is actually better than having it built in—and Rust certainly has that.
-
@bulb said in Enlightened:
But that sounded like you have a language that does. So do you?
No I don't.
It sounded like you said C++ does, which surprised me since it doesn't even have a library for it out of the box. But, as I said, the ability to provide your own library solution is fine.
-
@Bulb said in Enlightened:
@topspin said in Enlightened:
@Bulb said in Enlightened:
Well, still a bit worse than C++,
C++ supports fixed-point arithmetic?
Sure, the class mechanism / operator overloading allows you to write your own fixed-point type that behaves just like a built-in one would. That's good enough, IMO, but as far as I know it doesn't come with such a type out of the box.I use quite a few languages, but none of them has fixed-point type built in. Which one you had in mind?
Do SQL's
decimalandnumerictypes count?
-
@masonwheeler said in Enlightened:
@pie_flavor said in Enlightened:
You have missed the point.
Hmm?
The point is that controlling memory allocation is not important in Java, at least not in the way those people think it is.
-
@topspin said in Enlightened:
Fixed point seems much simpler to get correct than IEEE-754. Why wouldn't a library work well for that?
It's different. Unlike with floating point, you need to pay a lot more attention to scaling (and there are far more fixed point types) and a lot more shifting. This makes algorithm choice far more sensitive, as it is very easy to do things wrong and lose loads of information. Everything is particularly awkward when you also don't have general division (a common case on low-end CPU cores; division takes quite a lot of gates).
If your scaling of the problem is correct, you've potentially got better accuracy with fixed point than with floating point (of the same size) since you've effectively only got mantissa, no exponent. If your scaling is wrong, you're far worse. This makes having a numerical analyst on team more important than usual (and a very large fraction of people doing numerically-heavy code would really do much better work if they did that; just doing it all in
doublereally isn't enough to make everything work).
-
@topspin said in Enlightened:
Why do all these
embedded vendors even ship their own C compiler?The armcc compiler generates better code than gcc; in particular it produces code that is more energy efficient and compact, and they are key concerns in embedded systems. (I don't know if gcc even allows you to ask for optimisations for energy usage, but I'd be startled if it had the cost models needed for that sort of thing.) There's not very much in it these days, but it is noticeable for a few things.
Apart from legacy code bases, is there any reason to ship more than the codegen back-end for LLVM / GIMPLE (or whatever gcc uses)? The code-gen really shouldn't need to care if the input was C or Rust or whatever, and you don't need to deal with front-end bugs where your compiler doesn't get some C features correct.
Nobody serious uses LLVM for embedded targets at the moment. The clang front end simply doesn't currently support fixed point types (and the LLVM back end definitely doesn't, though that's perhaps less fatal; you could work with integer operations there).
The key is that the existing code that uses them in C uses the type system described in
stdfix.h. That's fairly well standardised (at least to the point where there's multiple implementations), but completely ignored by compiler vendors not used to embedded work. The core issue is that it defines two entirely new types of number type,_Accumand_Fract, which can take all the modifiers that integer types usually accept (sounsigned long _Fractis definitely a thing). That causes tooling not adapted to work on these things to completely choke. Yes, there's also syntax for constants of these types, but that's less problematic for the unknowing IDE.
-
-
@lb_ While I agree with the title of this video, I very much disagree with the slide that says teaching people to write
cout << "Hello " << myVar;is okay. No, people should learn format strings from the start, because it's impossible to translate programs that don't use format strings for everything. Way too many programmers don't think about that at all and every useful program will need to be translated at some point, so it has to be ingrained in people's minds from the start.
-
@dfdub said in Enlightened:
No, people should learn format strings from the start, because it's impossible to translate programs that don't use format strings for everything.
It's impossible to translate most format strings either. Either you make your translation tools to account for huge grammar differences between languages - especially in how quantities work - or you end up with your entire program being like "the number of unread emails you have in your mailbox is 2."
-
@boomzilla said in Enlightened:
I'm always amazed at how many standards readers we have on here.
Some language standards can be surprisingly readable. C++, of course, is not one of those languages…
I know I'm a weirdo because I always look at the official documentation for answers (I never copy from SO without looking up the official document and double-checking whether the answer is correct), but I honestly think that everyone should at least try to do that most of the time.
-
@dfdub said in Enlightened:
@boomzilla said in Enlightened:
I'm always amazed at how many standards readers we have on here.
Some language standards can be surprisingly readable.
Example?
-
@dkf said in Enlightened:
It usually seems to be written by people who feel that they need to take a stand on preventing the great vowel shortage, and to keep identifiers as short as possible.
According to rumors (I haven't checked), one of our products has a huge C code base in which no variable name is longer than 8 characters due to some bug in the only compiler for some weird architecture we have to support. I am not planning on ever touching that repository.
-
@dfdub said in Enlightened:
While I agree with the title of this video, I very much disagree with the slide that says teaching people to write cout << "Hello " << myVar; is okay. No, people should learn format strings from the start, because it's impossible to translate programs that don't use format strings for everything.
I personally prefer format strings (mostly because they are way more readable), but I'm not sure about teaching. While I dislike the C++ stream formatting because it's so bloody verbose, one big advantage is that they infer the type of the thing being printed, and that they are easy to extend to handle custom types.
Regarding translation ... if you're teaching a course for beginners, you're concerned about students understanding variables, functions and classes/objects, and how to actually write a program that does something sensible. Being able to do translations is rather far down the list of priorities; there's more important stuff that already ends up being skipped due to time limits.
That being said ... the proposals regarding formatting will maybe give us something that makes it possible to use format strings and have type inference, so IMO it will be an improvement over the C++ streams in all ways.
-
One of the fun things at Build 2018 was the announcement that Samsung is highly dedicated to .NET and Xamarin, and will fully support it in Tizen.
This thread had something to do with that at some point, I think?
-
@masonwheeler said in Enlightened:
It's quite possible to control memory allocation in Java. What it's not possible to control is memory deallocation,
You're wrong:
http://www.docjar.com/docs/api/sun/misc/Unsafe.html#freeMemory(long)
-
@pie_flavor said in Enlightened:
@masonwheeler said in Enlightened:
The point is that controlling memory allocation is not important in Java, at least not in the way those people think it is.Unless you're doing stuff in Java that you really shouldn't be doing in Java. See Hadoop.
-
@dfdub said in Enlightened:
Unless you're doing stuff in Java that you really shouldn't be doing in Java.
Using it?
-
@gąska said in Enlightened:
It's impossible to translate most format strings either. Either you make your translation tools to account for huge grammar differences between languages - especially in how quantities work - or you end up with your entire program being like "the number of unread emails you have in your mailbox is 2."
Now you're just arguing that
printfshould support format strings that reference arguments by index (like other languages do) and you're absolutely right. But having a regular format string is already much better than having nothing coherent at all.
-
@gąska said in Enlightened:
@dfdub said in Enlightened:
Some language standards can be surprisingly readable.
Example?
The Java Language Specification wasn't too bad the last time I checked.
.
