It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
dtgreene: Is D useful for embedded programming?

In particular, for embedded, here are the sort of features that are important:
* Not needing a garbage collector, and not need a substantial runtime (garbage collectors are terrible for real-time, and apparently also need a lot of extra RAM to be efficient, which we may not have)
* Be able to run without the standard library (there may not be one available, and there may not be enough space for one); this includes not having the usual start files
Yes it could be useful for embedded programming, although maybe it's not all ready yet, i haven't kept close attention on it's progress for a little while.

The standard library and a couple built-in features allocate memory using/relying on the garbage collector, but it's possible to avoid it or supply a different memory allocation removing those needs. Last i remember a portion of the Standard library was moving more functions away from the garbage collector.

But it really depends on what features are needed in an embedded system, and how much of the environment needs setting up before it's used. If it's number crunching and you don't need text processing or are appending/manipulating arrays and classes, avoiding the GC is fairly easy.

If you don't rely on the GC/STDLib/LTS, you could likely write structs and/or functions and call them from C/C++ avoiding the Standard library and runtime altogether (as they just have stack allocation during the call and cleanup afterwards). Though name mangling might be a pain, so limit the public/visible API.

avatar
dtgreene: * Be able to call routines written in assembly language, or allow for inline assembly (this may be occasionally necessary to access features of the hardware that are not exposed by a higher level language, like I/O ports on x86, or the SPM instruction on the AVR)

* Be able to read and write to arbitrary memory locations (this may be used to access hardware registers that are mapped into the address space, or for DMA if the system supports it) (In C, this can be done easily by casting an integer to a pointer)

So, how does D fare in this respect?
Already present, as pointers and asm code can be injected directly. Worst case you can use a union to force a number into an address and use that. Sorta an ugly workaround.

Though there isn't the violate keyword, which i would think is the biggest worry on this front.
Post edited February 22, 2019 by rtcvb32
avatar
dtgreene: … Suppose that we're developing software for an embedded system, and we have a C++ compiler that… does not support constexpr. … For the software being developed, it has been determined that we need to pre-compute some values at compile time. … So, looking at the situation, we have found two reasonable options. Which of these options would be a better choice?

1. Use template metaprogramming to compute the values at compile-time. This, while clever, can be a pain for C++ programmers who aren't used to it to understand, and it is a bit ugly.

2. Write a program on the host system that, when executed, would generate a C++ source file containing the computed values, and work it into our build system. This means we can use any language available on the host, but it does make the build a bit more complicated.
I'm late to the party, but I concur with everyone else. The second alternative doesn't need to be updated (programmatically), whereas the template (if I'm reading your question aright) might be adjusted over time. A reliable, pre-rendered program is not reliant on the correct construction of the template, which you have also noted is problematic in any case.

On a related note, one of the main drivers of all my coding as I matured was to make it readable (post factum). This I learnt through face-planting walls of text that I could not decipher even a few days after I wrote them (C being a particular stand-out example of this phenomenon). Try reading legacy code written by someone else, with the idea to improve it.

Best practice demands legibility (less time to interpret spaghetti code). If it takes more time to understand what the subroutine does than to update it, then the rate of change ought to leverage the clarity of documentation / nomenclature. By all means have fast, clean, small, tight routines for looped action; adding a few judicious variable and constant names can make a big difference. (Calling everything x might be quicker to write, but it's maddening to debug / read. :)
low rated
I get a job in one company, and so I was given the task (deadlines a week) to write a Python program for log parsing, the future employer is aware from my resume that I don’t know Python and in general is very weak in programming, but despite it still set a task for me. Who can I pay for programming assignment?
Post edited February 18, 2020 by corson96
avatar
corson96: I get a job in one company, and so I was given the task (deadlines a week) to write a Python program for log parsing, the future employer is aware from my resume that I don’t know Python and in general is very weak in programming, but despite it still set a task for me.
Python is quite an easy language. I'm sure you can google what you need. Google and stackoverflow are your friends.
avatar
corson96: I get a job in one company, and so I was given the task (deadlines a week) to write a Python program for log parsing, the future employer is aware from my resume that I don’t know Python and in general is very weak in programming, but despite it still set a task for me.
avatar
blotunga: Python is quite an easy language. I'm sure you can google what you need. Google and stackoverflow are your friends.
thanks, I'll try
avatar
blotunga: Python is quite an easy language. I'm sure you can google what you need. Google and stackoverflow are your friends.
avatar
corson96: thanks, I'll try
What kind of programm do you need to create with Python?
i add my vote to 2

I like the SOA kind of approach where you have small, focused services that do their job. they can be independantly maintained and tested. if you need to fix one you can release the fixed version without having to redeploy everything (unless you're doing a major overhaul of the interface ofc, but then there are ways of dealing with interfaces and breaking changes and versioning - but this seems out of scope of what you're doing anyway)

do you even need something that computes a result and passes it back at which point you include and compile? can it not be interrgoated during runtime? the values can still be precomputed and held in a cache on the other service and updated when feasable (over weekends / at night when noone is working)?

EDIT: oh, i see the thread was necro'ed and a new subject has been injected... well.. i hope whatever it was you were doing turned out ok)
Post edited February 21, 2020 by zenstar
avatar
zenstar: do you even need something that computes a result and passes it back at which point you include and compile? can it not be interrgoated during runtime? the values can still be precomputed and held in a cache on the other service and updated when feasable (over weekends / at night when noone is working)?

EDIT: oh, i see the thread was necro'ed and a new subject has been injected... well.. i hope whatever it was you were doing turned out ok)
Yes, this thread was necroed, but I am still interested in this sort of discussion. (I note that I wasn't actually working on anything where this came up, but rather I was just curious what people thought would work best in this situation.)

I can think of a few reasons why computing the vales at run-time might not be viable:

1. The value needs to be used at a place where the language requires a constant, like the size of an array or as a template parameter. Computing the value at run-time won't work, as it won't be a constant and therefore the program will fail to compile. (Keep in mind that dynamic memory management isn't always a realistic option, like on microcontrollers with limited memory.)

2. The target device is not powerful enough to do the computations in a reasonable amount of time. For example, maybe the target device is a microcontroller, like the one in the Arduino Uno (which uses an AVR chip).

3. RAM is at a premium, and the result needs to be stored somewhere else, like in a microcontroller's ROM. For example, on the AVR, program and data have separate address spaces, and program memory can't be written to at run time (unless the program counter is below a certain value, and keep in mind that flash memory has a limited number of writes before it dies). Perhaps we are runing out of RAM, but still have some space left in program memory to store the computed values.

Also, you seem to suggest taking the values from some server or other computer at run-time, but that won't work if the system is a microcontroller that has no connection to the outside world once it's deployed. (We're not talking about an Internet of Things device here.)
avatar
zenstar: do you even need something that computes a result and passes it back at which point you include and compile? can it not be interrgoated during runtime? the values can still be precomputed and held in a cache on the other service and updated when feasable (over weekends / at night when noone is working)?

EDIT: oh, i see the thread was necro'ed and a new subject has been injected... well.. i hope whatever it was you were doing turned out ok)
avatar
dtgreene: Yes, this thread was necroed, but I am still interested in this sort of discussion. (I note that I wasn't actually working on anything where this came up, but rather I was just curious what people thought would work best in this situation.)

I can think of a few reasons why computing the vales at run-time might not be viable:

1. The value needs to be used at a place where the language requires a constant, like the size of an array or as a template parameter. Computing the value at run-time won't work, as it won't be a constant and therefore the program will fail to compile. (Keep in mind that dynamic memory management isn't always a realistic option, like on microcontrollers with limited memory.)

2. The target device is not powerful enough to do the computations in a reasonable amount of time. For example, maybe the target device is a microcontroller, like the one in the Arduino Uno (which uses an AVR chip).

3. RAM is at a premium, and the result needs to be stored somewhere else, like in a microcontroller's ROM. For example, on the AVR, program and data have separate address spaces, and program memory can't be written to at run time (unless the program counter is below a certain value, and keep in mind that flash memory has a limited number of writes before it dies). Perhaps we are runing out of RAM, but still have some space left in program memory to store the computed values.

Also, you seem to suggest taking the values from some server or other computer at run-time, but that won't work if the system is a microcontroller that has no connection to the outside world once it's deployed. (We're not talking about an Internet of Things device here.)
ah, fair enough. so you need the values at compile time.
i'd still say option 2. it's more faff, but ultimately cleaner especially if the process is documented