If I am using assembly language to code for an embedded systems. Can I use RTOS and asssembly language ? Usually rtos is used when a complex software is involved. Is there any technical or theoretical constraint ?
Asked
Active
Viewed 941 times
0
-
3Considering that all higher-level languages eventually turn into assembly anyway; no, of course there's no reason you couldn't write your application in assembly and write an RTOS in assembly. Some RTOS scheduler routines are actually written in assembly. Now, the question you need to ask yourself is "do I need an RTOS to achieve the objectives of my software." That we cannot answer for you... – Ross Oct 03 '13 at 18:59
-
I wouldn't equate RTOS with complex software specifically. There's plenty of complex software that does not have real time needs. – Brian Knoblauch Oct 03 '13 at 20:28
-
@Knoblauch So do you want to say that RTOS will be only used when real time requirments are necessary ? – fahim Oct 04 '13 at 08:28
-
@fahim: I would say that an RTOS is neither only applicable to real-time requirements, or even that an RTOS is necessary to meet real-time requirements. Often it is convenient and natural to partition an application into independent threads regardless of any real-time requirements, and for that a task scheduler is necessary and in embedded systems most OS schedulers are real-time capable, but not all tasks necessarily have hard real-time requirements. While Brian says that complex software need not have real time requirements, equally an RTOS might be convenient even for simple systems. – Clifford Oct 10 '13 at 09:06
2 Answers
1
Certainly the answer is yes. How that is done may depend on the selected architecture, and the specific RTOS.
Most RTOS kernels are provided as static link libraries to which you link your application code to form a monolithic load image. A few such as QNX are full operating systems that dynamically load and execute applications at runtime. In the latter case, making OS calls from assembler should be dealt with in the OS documentation. In the case of a statically linked RTOS library, the assembler interface will normally conform to the ABI and calling convention of the target architecture, and this will be documented for the architecture, and possibly the RTOS itself.
Most RTOS products are designed with a C API interface, documentation for your target on calling C code from assembler then applies. You may find this information in the assembler or RTOS documentation.
With all that said, the argument for using assembler is usually to maintain tight control over code size and performance, but by using a large(ish) third-party library, you to some extent loose that control, and might arguably do as well to simply use C or C++.
The truth is that in most cases you need to be highly knowledgeable about a specific instruction set to beat an optimizing C compiler in both performance and code size, and even if you have that knowledge, to hand optimise large bodies of assembler is seldom worth the effort from a productivity point of view. In large assembly code bases, it is common for reasons of productivity to use a large amount of boiler-plate and macro generated code - this will often be sub-optimal for a specific use while a compiler optimiser can consider the implementation of every part of the code during translation. See this article on embedded.com by Colin Walls (read the comments too - including mine - for balance, and just for the fun of embedded geeks in disagreement).
Clifford
- 88,407
- 13
- 85
- 165
-1
It actually depends on the OS. Most known OSes allows using assembly language programming, but some of them makes it very uncomfortable (for example Mac OS X, that puts very strange requirements for the stack alignment on API calls).
I can imagine some OS that will make assembly programming absolutely impossible, but such OS probably will limit itself as well in some features.
So, the rule is - if the OS allows running of compiled binary files, then it allows assembly language programming.
It is completely another talk how easy is to create such programs. Good API documentation is essential.
johnfound
- 6,857
- 4
- 31
- 60
-
The question was specifically about RTOS rather than general purpose OS. Most RTOS are simply static link libraries that are linked with application code to form a monolithic application image. In that sense comparison with OSX really does not apply. – Clifford Oct 06 '13 at 09:06
-
@Clifford - if something is called OS, it must have most of the OS properties, regardless of the binary format. So, every OS provides some API with some calling conventions. I can't know all OSes (real time or not) but everything I wrote in the answer concerns all types of OS. And the person asked the question is obviously satisfied by the answer. – johnfound Oct 08 '13 at 21:21
-
I think the answer is not specific enough, given that the question was *very* specific. In then end it is simply a case of constructing a call that matches the calling convention of teh OS API which is invariably a C calling convention in an RTOS library. The simple answer is that you call the RTOS from assembler in the same way toy call any C language code from assembler. Either way it *never* "depends on the OS" - if you can't do it in assembler then you cannot do it on the machine at all since executing machine level instructions is all the computer can do. – Clifford Oct 09 '13 at 20:13
-
@Clifford - I am sure **your** answer is much, much better. Of course. :P – johnfound Oct 09 '13 at 20:14