Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #28176 > unrolled thread
| Started by | Clifford Heath <no.spam@please.net> |
|---|---|
| First post | 2018-10-10 12:05 +1100 |
| Last post | 2018-10-15 07:30 -0700 |
| Articles | 20 on this page of 104 — 19 participants |
Back to article view | Back to comp.arch.embedded
$0.03 microcontroller Clifford Heath <no.spam@please.net> - 2018-10-10 12:05 +1100
Re: $0.03 microcontroller lasselangwadtchristensen@gmail.com - 2018-10-10 16:12 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-10 17:51 -0700
Re: $0.03 microcontroller lasselangwadtchristensen@gmail.com - 2018-10-10 18:56 -0700
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-10 19:29 -0700
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-11 11:39 +0300
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-11 16:08 -0700
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-12 08:50 +0200
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-12 09:44 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-12 21:30 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-12 22:06 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-12 23:45 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-13 21:47 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-14 11:58 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 08:14 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-11 09:27 +0100
Re: $0.03 microcontroller Klaus Kragelund <klauskvik@hotmail.com> - 2018-12-26 02:23 -0800
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 10:44 +0200
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-15 07:29 -0700
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-16 09:19 +0200
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-16 13:48 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-15 21:34 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-16 09:29 +0200
Re: $0.03 microcontroller Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-10-15 21:22 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-16 10:00 +0200
Re: $0.03 microcontroller Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-10-16 22:52 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-16 14:01 -0700
Re: $0.03 microcontroller Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-10-17 00:03 +0200
Re: $0.03 microcontroller Clifford Heath <no.spam@please.net> - 2018-10-17 09:22 +1100
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-16 15:29 -0700
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-17 00:46 +0200
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-17 09:35 +0300
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-17 09:31 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-17 07:08 -0700
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-17 18:37 +0300
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-17 10:04 -0700
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-17 23:07 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-17 08:23 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-17 19:43 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-17 20:24 +0200
Re: $0.03 microcontroller George Neuner <gneuner2@comcast.net> - 2018-10-17 11:31 -0400
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-05 12:41 +0100
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-12 09:11 -0700
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-13 12:46 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-13 05:06 -0700
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-13 18:00 +0300
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-13 18:27 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-13 20:50 +0300
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-14 14:26 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-13 18:20 -0700
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-14 08:53 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-14 08:55 +0200
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-14 14:32 +0200
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-13 18:21 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-13 18:32 -0700
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-13 19:02 -0700
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-14 14:37 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-14 14:59 +0200
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-13 11:06 -0700
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 18:31 +0300
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 19:46 +0300
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 19:59 +0300
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-13 21:31 +0300
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 22:19 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-13 21:24 +0200
Re: $0.03 microcontroller Niklas Holsti <niklas.holsti@tidorum.invalid> - 2018-10-13 22:50 +0300
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-14 14:39 +0200
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-15 05:11 -0700
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-13 21:03 +0300
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-13 18:25 -0700
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 14:20 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-21 16:27 +0300
Re: $0.03 microcontroller jim.brakefield@ieee.org - 2018-10-21 07:47 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-21 08:08 -0700
Re: $0.03 microcontroller jim.brakefield@ieee.org - 2018-10-21 09:31 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-21 10:51 -0700
Re: $0.03 microcontroller jim.brakefield@ieee.org - 2018-10-21 12:44 -0700
Re: $0.03 microcontroller Brett <ggtgp@yahoo.com> - 2018-10-22 00:28 +0000
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-21 21:43 +0200
Re: $0.03 microcontroller Phil Martel <pomartel@comcast.net> - 2018-10-21 11:03 -0400
Re: $0.03 microcontroller George Neuner <gneuner2@comcast.net> - 2018-10-21 20:59 -0400
Re: $0.03 microcontroller Michael Kellett <mk@mkesc.co.uk> - 2018-10-11 14:04 +0100
Re: $0.03 microcontroller David Brown <david.brown@hesbynett.no> - 2018-10-11 15:56 +0200
Re: $0.03 microcontroller Michael Kellett <mk@mkesc.co.uk> - 2018-10-13 09:35 +0100
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-13 13:06 -0700
Re: $0.03 microcontroller Michael Kellett <mk@mkesc.co.uk> - 2018-10-14 11:30 +0100
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-12 10:18 +0200
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-10-12 21:39 +0300
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-08 13:53 +0100
Re: $0.03 microcontroller Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-11-08 15:08 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-08 14:34 +0100
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-11-08 21:52 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-08 21:56 +0100
Re: $0.03 microcontroller upsidedown@downunder.com - 2018-11-09 00:35 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-11-09 09:00 +0100
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 14:19 +0200
Re: $0.03 microcontroller Tim <cpldcpu+usenet@gmail.com> - 2018-10-14 01:46 +0200
Re: $0.03 microcontroller Theo <theom+news@chiark.greenend.org.uk> - 2018-10-14 10:55 +0100
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-24 15:57 +0200
Re: $0.03 microcontroller Philipp Klaus Krause <pkk@spth.de> - 2018-10-15 14:35 +0200
Re: $0.03 microcontroller raimond.dragomir@gmail.com - 2018-10-15 06:05 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-15 07:19 -0700
Re: $0.03 microcontroller Paul Rubin <no.email@nospam.invalid> - 2018-10-15 07:26 -0700
Re: $0.03 microcontroller gnuarm.deletethisbit@gmail.com - 2018-10-15 07:30 -0700
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-16 13:48 +0200 |
| Message-ID | <pq4j6l$h0u$1@dont-email.me> |
| In reply to | #28240 |
On 16/10/18 09:19, Philipp Klaus Krause wrote: > Am 15.10.2018 um 16:29 schrieb Paul Rubin: >> Philipp Klaus Krause <pkk@spth.de> writes: >>> Compilers can sometimes overly local variables on non-reentrant >>> functions as an optimization, but that will only work for some cases; >>> often it would require link-timeoptimization, which is not that common >>> in compilers for small µCs. >> >> Normally you'd use whole-program optimization, I thought. I don't know >> if SDCC supports that, but GCC does, as do the more serious commercial >> embedded compilers. >> > > Does GCC support any of these very simple µC architectures? No. > I thought > anyhting supported by GCC tends to have rather powerful insturction sets > and plenty of registers aynway, so functions could be made reentrant by > default without any problems resulting. Most gcc targets are quite powerful, with plenty of registers - and re-entrancy is not a problem. Some are a bit weaker, like the 8-bit AVR, and get inefficient with complicated stack usage. But it does not support the 8-bit CISC accumulator-based devices that SDCC targets. > > While some link-time optimizations are commonly requested features for > SDCC, currently none are supported. In SDCC, even inter-procedural > optimizations within the same translation unit are not as powerful as > they should be. > Well, there always is a lot of work to do on SDCC, and there are only a > few volunteers with time to work on it. So SDCC developers priorize > (usually by personal preferences). > > Still, when looking at the big picture, SDCC is doing quite well > compared to other compilers for the same architectures (see e.g. > http://www.colecovision.eu/stm8/compilers.shtml - comparison from early > 2018, around the time of the SDCC 3.7.0 release - current SDCC is 3.8.0). > > Philipp >
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-15 21:34 +0300 |
| Message-ID | <6nl9sd14ae130l1ddhven1c02lp6bnom48@4ax.com> |
| In reply to | #28228 |
On Mon, 15 Oct 2018 10:44:07 +0200, Philipp Klaus Krause <pkk@spth.de> wrote: >Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >> >> With such small ROM/RAM sizes, who needs reentrant functions ? > >Everyone. With an efficent stack-pointer-relative addresing mode, you >put all local varibles on the stack and only need as much RAM as the >local variables along the longest path in the call tree. If you do not have efficient stack pointer relative addressing modes, why would you put local variables on stack ? >If your local variables are all static, the local variables of two >functions that never get called at the same time still both takespace in >RAM at the same time. Just create global variables Tmp1, Tmp2, Tmp3 ... and use these as function local variables. As long as two functions do not call each other directly or indirectly, you can safely use these global variables as function local variables. To make your program even prettier, use function specific aliases for Tmp1, Tnp2 etc.. by using #define statements in C or multiple labels in assembly language storage allocation. > >Compilers can sometimes overly local variables on non-reentrant >functions as an optimization, but that will only work for some cases; >often it would require link-timeoptimization, which is not that common >in compilers for small µCs. Why do you need a linker for such small processor.? Since you are going to use a cross-copiler on a PC with mega/gigabytes of memory, you just compile/assemble everything into binary at once. >Example: main() calls f() and g(); both f() and g() call h(). All four >functions are in different translation units, f() and g() both use a lot >of local variables, while main() and h() use little. Without link-time >optimization, the compiler will use about as much RAM as f() and g() >together, when the local variables are static. When they are put on the >stack, it will only need as much RAM as either f() or g(). See above, no need for linker or stack variables. The question is, do you even need full scale parameter passing ? Function h() could use some predefined memory locations and both f() and g() can put the parameter into those memory locations before calling h(). Only those parameters that are different when calling from f() or g() needs to be passed, h() can get the parameters that are the same in both cases do not need to be passed, h() knows the parameter already at startup. Of course such tricks becomes impractical with larger system, but with 1 KW / 64 B, this should definitely be doable.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-16 09:29 +0200 |
| Message-ID | <pq440q$tpe$1@solani.org> |
| In reply to | #28238 |
Am 15.10.2018 um 20:34 schrieb upsidedown@downunder.com: > On Mon, 15 Oct 2018 10:44:07 +0200, Philipp Klaus Krause <pkk@spth.de> > wrote: > >> Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >>> >>> With such small ROM/RAM sizes, who needs reentrant functions ? >> >> Everyone. With an efficent stack-pointer-relative addresing mode, you >> put all local varibles on the stack and only need as much RAM as the >> local variables along the longest path in the call tree. > > If you do not have efficient stack pointer relative addressing modes, > why would you put local variables on stack ? 1) The question was "With such small ROM/RAM sizes, who needs reentrant functions ?". And it was a reply to a post were the lack of a effiednt sp-relative addressing mode was cited as a disadvatage of the Padauk. So my reasoning was, that one would want local variables on the stack, even for small RAM / ROM, so the lack of sp-relative addressing is a disadvatage - as one has to either put local variables elsewhere or handle stackk accesses in an inefficent way. 2) There will still be some use cases for reentrant functions. And since the Padauk has a relatively large ROM - at least compared to the RAM (the ROM/RAM ratio seems far higher than on typical STM8 or MCS-51 devices), when speed doesn't matter, maybe it might still be worth putting variables on the stack. A compiler should provide an option for that (as, e.g. SDCC does for architectures without efficnet stack access, such as MCS-51 or HC08). > >> If your local variables are all static, the local variables of two >> functions that never get called at the same time still both takespace in >> RAM at the same time. > > Just create global variables Tmp1, Tmp2, Tmp3 ... and use these as > function local variables. As long as two functions do not call each > other directly or indirectly, you can safely use these global > variables as function local variables. I'd rather write idiomatic C anmd leave such optimizations to the compiler. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2018-10-15 21:22 +0200 |
| Message-ID | <g2k7o2Fah3jU1@mid.dfncis.de> |
| In reply to | #28228 |
Am 15.10.2018 um 10:44 schrieb Philipp Klaus Krause: > Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >> >> With such small ROM/RAM sizes, who needs reentrant functions ? > > Everyone. Absolutely not. Reentrant functions are a massive nuisance on fully embedded systems, if only because they routinely make it impossible to determine the actual stack size usage. > With an efficent stack-pointer-relative addresing mode, you > put all local varibles on the stack and only need as much RAM as the > local variables along the longest path in the call tree. And without such an addressing mode, you don't, because you'll suffer badly in every conceivable aspect. > If your local variables are all static, the local variables of two > functions that never get called at the same time still both takespace in > RAM at the same time. So don't mark them 'static', unless they actually have to be. > Compilers can sometimes overly local variables on non-reentrant > functions as an optimization, but that will only work for some cases; > often it would require link-timeoptimization, which is not that common > in compilers for small µCs. On the contrary: it's precisely the compilers for such stack-starved architectures (e.g. the 8051) that have been coupling behind-the-scenes static allocation of automatic variables with whole-program overlay analysis since effectively forever. They really had to, because the alternative would be painful to the point of being unusable.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-16 10:00 +0200 |
| Message-ID | <pq45rr$v0k$1@solani.org> |
| In reply to | #28239 |
Am 15.10.2018 um 21:22 schrieb Hans-Bernhard Bröker: > Am 15.10.2018 um 10:44 schrieb Philipp Klaus Krause: >> Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >>> >>> With such small ROM/RAM sizes, who needs reentrant functions ? >> >> Everyone. > > Absolutely not. Reentrant functions are a massive nuisance on fully > embedded systems, if only because they routinely make it impossible to > determine the actual stack size usage. What is the problem? Either you use recursion - in which case the functions need to be reentrant, there is no alternative, or you don't. In the latter case you'd need to do whole-program analysis to efficiently overlay the variables - a very similar analysis could tell you the the total stack usage. > >> With an efficent stack-pointer-relative addresing mode, you >> put all local varibles on the stack and only need as much RAM as the >> local variables along the longest path in the call tree. > > And without such an addressing mode, you don't, because you'll suffer > badly in every conceivable aspect. Yes. So compilers like SDCC when targeting MCS-51 or HC08 don't use the stack by default (--stack-auto puts local variables on the stack per-file, __reentrant does so per function). > >> Compilers can sometimes overly local variables on non-reentrant >> functions as an optimization, but that will only work for some cases; >> often it would require link-timeoptimization, which is not that common >> in compilers for small µCs. > > On the contrary: it's precisely the compilers for such stack-starved > architectures (e.g. the 8051) that have been coupling behind-the-scenes > static allocation of automatic variables with whole-program overlay > analysis since effectively forever. They really had to, because the > alternative would be painful to the point of being unusable. > Well, SDCC when targeting MCS-51 or HC08 would be the combination that I know a bit about (though personally, I mostly use SDCC to target Z80 or STM8, which can both use the stack efficiently). SDCC doesn't really have link-time optimization yet, compilation units are handled independently. Regarding different compilation units, it can still overlay the variables of leaf functions - i.e. non-reentrant differnet that do not call non-reentrant functions, but not much more. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2018-10-16 22:52 +0200 |
| Message-ID | <g2n1cmFs167U1@mid.dfncis.de> |
| In reply to | #28242 |
Am 16.10.2018 um 10:00 schrieb Philipp Klaus Krause: > Am 15.10.2018 um 21:22 schrieb Hans-Bernhard Bröker: >> Am 15.10.2018 um 10:44 schrieb Philipp Klaus Krause: >>> Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >>>> >>>> With such small ROM/RAM sizes, who needs reentrant functions ? >>> >>> Everyone. >> >> Absolutely not. Reentrant functions are a massive nuisance on fully >> embedded systems, if only because they routinely make it impossible to >> determine the actual stack size usage. > > What is the problem? The major part of it is that I mixed up Reentrance with Recursion there ... sorry for that. OTOH, one does tend to influence the other. Without recursion, one would only really need reentrance to be able to call the same function from separate threads of execution. On controllers this small, that would only happen if you're calling the same function from inside an interrupt handler and the main loop. And frankly: you really don't want to do that. If an ISR on this kind of hardware becomes big enough you feel the need to split it into sub-functions, that almost certainly means you've picked entirely the wrong tool for the job. In other words: for this kind of system (very small, with rotten stack-based addressing), not only doesn't everyone need re-entrant functions, it's more like nobody does. >> On the contrary: it's precisely the compilers for such stack-starved >> architectures (e.g. the 8051) that have been coupling behind-the-scenes >> static allocation of automatic variables with whole-program overlay >> analysis since effectively forever. They really had to, because the >> alternative would be painful to the point of being unusable. >> > > Well, SDCC when targeting MCS-51 or HC08 would be the combination that I > know a bit about I don't think anyone has ever seriously claimed SDCC to be anywhere near the pinnacle of compiler design for the 8051. ;-P Frankly, just looking at statements in this thread has me thinking that the usual suspects among commercial offerings from 20 years ago might still run circles around it today. > SDCC doesn't really have link-time optimization yet, compilation > units are handled independently. Well, given the gigantic scale differences between the target hardware and the build host, just turning the whole thing into a single compilation unit (by force, if necessary) should really be a no-brainer.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-16 14:01 -0700 |
| Message-ID | <c6daebfa-d007-4f41-853e-4894c6093ea1@googlegroups.com> |
| In reply to | #28245 |
On Tuesday, October 16, 2018 at 4:52:44 PM UTC-4, Hans-Bernhard Bröker wrote: > Am 16.10.2018 um 10:00 schrieb Philipp Klaus Krause: > > Am 15.10.2018 um 21:22 schrieb Hans-Bernhard Bröker: > >> Am 15.10.2018 um 10:44 schrieb Philipp Klaus Krause: > >>> Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: > >>>> > >>>> With such small ROM/RAM sizes, who needs reentrant functions ? > >>> > >>> Everyone. > >> > >> Absolutely not. Reentrant functions are a massive nuisance on fully > >> embedded systems, if only because they routinely make it impossible to > >> determine the actual stack size usage. > > > > What is the problem? > > The major part of it is that I mixed up Reentrance with Recursion there > ... sorry for that. > > OTOH, one does tend to influence the other. Without recursion, one > would only really need reentrance to be able to call the same function > from separate threads of execution. On controllers this small, that > would only happen if you're calling the same function from inside an > interrupt handler and the main loop. I don't believe this is correct. Reentrance is a problem any time a routine is entered again before it is exited from a prior call. This can happen without multiple threads when a routine is called from a routine that was ultimately called from within the routine. I suppose you might consider this to be recursion, but my point is this can happen without the intent of using recursion. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2018-10-17 00:03 +0200 |
| Message-ID | <g2n5i8FsqnbU1@mid.dfncis.de> |
| In reply to | #28246 |
Am 16.10.2018 um 23:01 schrieb gnuarm.deletethisbit@gmail.com: > On Tuesday, October 16, 2018 at 4:52:44 PM UTC-4, Hans-Bernhard > Bröker wrote: >> OTOH, one does tend to influence the other. Without recursion, >> one would only really need reentrance to be able to call the same >> function from separate threads of execution. On controllers this >> small, that would only happen if you're calling the same function >> from inside an interrupt handler and the main loop. > I don't believe this is correct. Reentrance is a problem any time a > routine is entered again before it is exited from a prior call. This > can happen without multiple threads when a routine is called from a > routine that was ultimately called from within the routine. I > suppose you might consider this to be recursion, Oh, there's no doubt about it: that's recursion all right. Some might prefer to qualify it as indirect recursion, a.k.a. a loop in the call graph, but it's still recursion. > but my point is this > can happen without the intent of using recursion. I'll asume we agree on this: unintended recursion is clear a bug in the code, every time. That could arguably be classified an actual benefit of using a such a stack-starved CPU architecture: any competent C compiler for it will have to perform call tree analysis anyway, so it finds that particular bug "en passant". More typical C toolchains relying on stack-centric calling conventions might not bother with such analysis, and thus won't see the bug. Until you use the accompanying stack size calculation tool, that is, which will barf.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2018-10-17 09:22 +1100 |
| Message-ID | <7xtxD.300199$LK2.258687@fx36.iad> |
| In reply to | #28248 |
On 17/10/18 09:03, Hans-Bernhard Bröker wrote: > Am 16.10.2018 um 23:01 schrieb gnuarm.deletethisbit@gmail.com: > Reentrance is a problem any time a >> routine is entered again before it is exited from a prior call. This >> can happen without multiple threads when a routine is called from a >> routine that was ultimately called from within the routine. I >> suppose you might consider this to be recursion, > Oh, there's no doubt about it: that's recursion all right. > Some might prefer to qualify it as indirect recursion, a.k.a. a loop in > the call graph, but it's still recursion. We call it mutual recursion.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-16 15:29 -0700 |
| Message-ID | <17ce742d-3e4d-4d2c-8434-ef625395467c@googlegroups.com> |
| In reply to | #28248 |
On Tuesday, October 16, 2018 at 6:03:55 PM UTC-4, Hans-Bernhard Bröker wrote: > Am 16.10.2018 um 23:01 schrieb gnuarm.deletethisbit@gmail.com: > > On Tuesday, October 16, 2018 at 4:52:44 PM UTC-4, Hans-Bernhard > > Bröker wrote: > > >> OTOH, one does tend to influence the other. Without recursion, > >> one would only really need reentrance to be able to call the same > >> function from separate threads of execution. On controllers this > >> small, that would only happen if you're calling the same function > >> from inside an interrupt handler and the main loop. > > > I don't believe this is correct. Reentrance is a problem any time a > > routine is entered again before it is exited from a prior call. This > > can happen without multiple threads when a routine is called from a > > routine that was ultimately called from within the routine. I > > suppose you might consider this to be recursion, > > Oh, there's no doubt about it: that's recursion all right. > > Some might prefer to qualify it as indirect recursion, a.k.a. a loop in > the call graph, but it's still recursion. > > > but my point is this > > can happen without the intent of using recursion. > > I'll asume we agree on this: unintended recursion is clear a bug in the > code, every time. Clearly there would be a bug, but it is just as much that the routine wasn't designed for recursion and that would be the most likely fix. > That could arguably be classified an actual benefit of using a such a > stack-starved CPU architecture: any competent C compiler for it will > have to perform call tree analysis anyway, so it finds that particular > bug "en passant". Are you swearing at me in French? ;) > More typical C toolchains relying on stack-centric calling conventions > might not bother with such analysis, and thus won't see the bug. Until > you use the accompanying stack size calculation tool, that is, which > will barf. Yeah, I'm not much of a C programmer, so I wouldn't know about such tools. What made me think of this is a problem often encountered by novices in Forth. Some system words use globally static data and can be called twice from different code before the first call has ended use of the data structure. Not quite the same thing as recursion, but the same result. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-17 00:46 +0200 |
| Message-ID | <pq5pp2$ekh$1@dont-email.me> |
| In reply to | #28248 |
On 17/10/2018 00:03, Hans-Bernhard Bröker wrote: > I'll asume we agree on this: unintended recursion is clear a bug in the > code, every time. I think we can agree that /any/ unintended action is a clear bug in the code! But recursion or re-entrancy without a clear purpose and careful limits on depths is a bug in the /design/, not just the code. When I am faced with someone else's code to examine or maintain, I often run it through Doxygen with "generate documentation for /everything/ - caller graphs, callee graphs, cross-linked source, etc." It can make it quick to jump around in the code. And recursive (or re-entrant, whichever you prefer) code stands out like a sore thumb, as long as the code is single-threaded - you get loops in the call graphs. The only other case is if interrupts call other functions - that won't be seen so easily.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2018-10-17 09:35 +0300 |
| Message-ID | <g2o3hvF3um2U1@mid.individual.net> |
| In reply to | #28251 |
On 18-10-17 01:46 , David Brown wrote:
...
> When I am faced with someone else's code to examine or maintain, I often
> run it through Doxygen with "generate documentation for /everything/ -
> caller graphs, callee graphs, cross-linked source, etc." It can make it
> quick to jump around in the code. And recursive (or re-entrant,
> whichever you prefer) code stands out like a sore thumb, as long as the
> code is single-threaded - you get loops in the call graphs.
Anecdote: some years ago, when I was applying a WCET analysis tool to
someone else's program, the tool found recursion. This surprised the
people I was working with, because they had generated call graphs for
the program, analysed them visually, and found no recursive, looping paths.
Turned out that they had asked the call-graph tool to optimize the size
of the window used to display the call-graphs. The tool did as it was
told, with the result that the line segments on the path for the
recursive call went down to the bottom edge of the diagram, then
*merged* with the lower border line of the diagram, followed that lower
border, went up one side of the diagram -- still merged with the border
line -- and then reentered the diagram to point at the source of the
recursive call, effectively making the loop very hard to see...
(It turned out that this recursion was intentional. At this point, the
program was sending an alarm message, but the alarm buffer was full, so
the alarm routine called itself to send an alarm about the full buffer
-- and that worked, because one buffer slot was reserved, by design, for
this "buffer full" alarm.)
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-17 09:31 +0200 |
| Message-ID | <pq6og6$nhj$1@dont-email.me> |
| In reply to | #28253 |
On 17/10/18 08:35, Niklas Holsti wrote:
> On 18-10-17 01:46 , David Brown wrote:
> ...
>> When I am faced with someone else's code to examine or maintain, I often
>> run it through Doxygen with "generate documentation for /everything/ -
>> caller graphs, callee graphs, cross-linked source, etc." It can make it
>> quick to jump around in the code. And recursive (or re-entrant,
>> whichever you prefer) code stands out like a sore thumb, as long as the
>> code is single-threaded - you get loops in the call graphs.
>
> Anecdote: some years ago, when I was applying a WCET analysis tool to
> someone else's program, the tool found recursion. This surprised the
> people I was working with, because they had generated call graphs for
> the program, analysed them visually, and found no recursive, looping paths.
>
> Turned out that they had asked the call-graph tool to optimize the size
> of the window used to display the call-graphs. The tool did as it was
> told, with the result that the line segments on the path for the
> recursive call went down to the bottom edge of the diagram, then
> *merged* with the lower border line of the diagram, followed that lower
> border, went up one side of the diagram -- still merged with the border
> line -- and then reentered the diagram to point at the source of the
> recursive call, effectively making the loop very hard to see...
Visual tools are helpful, but don't show everything!
On the other hand, they can show things that can be hard to quantify in
more rigorous tools. It is easy to look at the call graph of a function
and say "that function is a bowl of spaghetti, and needs restructured" -
it's harder to define rules or limits for an automatic checker that make
such judgements.
>
> (It turned out that this recursion was intentional. At this point, the
> program was sending an alarm message, but the alarm buffer was full, so
> the alarm routine called itself to send an alarm about the full buffer
> -- and that worked, because one buffer slot was reserved, by design, for
> this "buffer full" alarm.)
>
I can appreciate the purpose here, but I would rather have this:
static bool putAlarmInLog(alarmPtr slot, ...) { ... }
static alarmSlot_t alarmSlots[maxAlarmSlots];
static alarmSlot_t emergencyAlarmSlot;
static alarmPtr findFreeAlarmSlot(void) { ... }
void logAlarm(...) {
alarmPtr = findFreeAlarmSlot();
if (alarmPtr) {
putAlarmInLog(alarmPtr, ...);
} else {
putAlarmInLog(&emergencyAlarmSlot, "Buffer full");
}
}
Hoist the condition checks up a step, and put the actual storage
mechanism down a step, and you no longer have the re-entrancy. The code
is a lot easier to write, read, analyse and test.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-17 07:08 -0700 |
| Message-ID | <45d0a592-052b-429c-b9fd-518f177e895e@googlegroups.com> |
| In reply to | #28253 |
On Wednesday, October 17, 2018 at 2:35:46 AM UTC-4, Niklas Holsti wrote: > On 18-10-17 01:46 , David Brown wrote: > ... > > When I am faced with someone else's code to examine or maintain, I often > > run it through Doxygen with "generate documentation for /everything/ - > > caller graphs, callee graphs, cross-linked source, etc." It can make it > > quick to jump around in the code. And recursive (or re-entrant, > > whichever you prefer) code stands out like a sore thumb, as long as the > > code is single-threaded - you get loops in the call graphs. > > Anecdote: some years ago, when I was applying a WCET analysis tool to > someone else's program, the tool found recursion. This surprised the > people I was working with, because they had generated call graphs for > the program, analysed them visually, and found no recursive, looping paths. > > Turned out that they had asked the call-graph tool to optimize the size > of the window used to display the call-graphs. The tool did as it was > told, with the result that the line segments on the path for the > recursive call went down to the bottom edge of the diagram, then > *merged* with the lower border line of the diagram, followed that lower > border, went up one side of the diagram -- still merged with the border > line -- and then reentered the diagram to point at the source of the > recursive call, effectively making the loop very hard to see... > > (It turned out that this recursion was intentional. At this point, the > program was sending an alarm message, but the alarm buffer was full, so > the alarm routine called itself to send an alarm about the full buffer > -- and that worked, because one buffer slot was reserved, by design, for > this "buffer full" alarm.) Seems to me what actually failed was that they knew they had recursion in the design but didn't realize the fact that they didn't see the recursion in the call graphs was an error that should have been caught. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2018-10-17 18:37 +0300 |
| Message-ID | <g2p395FabtdU1@mid.individual.net> |
| In reply to | #28255 |
On 18-10-17 17:08 , gnuarm.deletethisbit@gmail.com wrote:
> On Wednesday, October 17, 2018 at 2:35:46 AM UTC-4, Niklas Holsti
> wrote:
>> On 18-10-17 01:46 , David Brown wrote: ...
>>> When I am faced with someone else's code to examine or maintain,
>>> I often run it through Doxygen with "generate documentation for
>>> /everything/ - caller graphs, callee graphs, cross-linked source,
>>> etc." It can make it quick to jump around in the code. And
>>> recursive (or re-entrant, whichever you prefer) code stands out
>>> like a sore thumb, as long as the code is single-threaded - you
>>> get loops in the call graphs.
>>
>> Anecdote: some years ago, when I was applying a WCET analysis tool
>> to someone else's program, the tool found recursion. This surprised
>> the people I was working with, because they had generated call
>> graphs for the program, analysed them visually, and found no
>> recursive, looping paths.
>>
>> Turned out that they had asked the call-graph tool to optimize the
>> size of the window used to display the call-graphs. The tool did as
>> it was told, with the result that the line segments on the path for
>> the recursive call went down to the bottom edge of the diagram,
>> then *merged* with the lower border line of the diagram, followed
>> that lower border, went up one side of the diagram -- still merged
>> with the border line -- and then reentered the diagram to point at
>> the source of the recursive call, effectively making the loop very
>> hard to see...
>>
>> (It turned out that this recursion was intentional. At this point,
>> the program was sending an alarm message, but the alarm buffer was
>> full, so the alarm routine called itself to send an alarm about the
>> full buffer -- and that worked, because one buffer slot was
>> reserved, by design, for this "buffer full" alarm.)
>
> Seems to me what actually failed was that they knew they had
> recursion in the design but didn't realize the fact that they didn't
> see the recursion in the call graphs was an error that should have
> been caught.
The guys creating and viewing the call-graphs were not the designers of
the program, either, so they didn't know, but for sure it was something
they should have discovered and remarked on as part of their work.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-17 10:04 -0700 |
| Message-ID | <fed88d91-0f59-40a8-9826-52baafd93aac@googlegroups.com> |
| In reply to | #28257 |
On Wednesday, October 17, 2018 at 11:37:14 AM UTC-4, Niklas Holsti wrote: > On 18-10-17 17:08 , gnuarm.deletethisbit@gmail.com wrote: > > On Wednesday, October 17, 2018 at 2:35:46 AM UTC-4, Niklas Holsti > > wrote: > >> On 18-10-17 01:46 , David Brown wrote: ... > >>> When I am faced with someone else's code to examine or maintain, > >>> I often run it through Doxygen with "generate documentation for > >>> /everything/ - caller graphs, callee graphs, cross-linked source, > >>> etc." It can make it quick to jump around in the code. And > >>> recursive (or re-entrant, whichever you prefer) code stands out > >>> like a sore thumb, as long as the code is single-threaded - you > >>> get loops in the call graphs. > >> > >> Anecdote: some years ago, when I was applying a WCET analysis tool > >> to someone else's program, the tool found recursion. This surprised > >> the people I was working with, because they had generated call > >> graphs for the program, analysed them visually, and found no > >> recursive, looping paths. > >> > >> Turned out that they had asked the call-graph tool to optimize the > >> size of the window used to display the call-graphs. The tool did as > >> it was told, with the result that the line segments on the path for > >> the recursive call went down to the bottom edge of the diagram, > >> then *merged* with the lower border line of the diagram, followed > >> that lower border, went up one side of the diagram -- still merged > >> with the border line -- and then reentered the diagram to point at > >> the source of the recursive call, effectively making the loop very > >> hard to see... > >> > >> (It turned out that this recursion was intentional. At this point, > >> the program was sending an alarm message, but the alarm buffer was > >> full, so the alarm routine called itself to send an alarm about the > >> full buffer -- and that worked, because one buffer slot was > >> reserved, by design, for this "buffer full" alarm.) > > > > Seems to me what actually failed was that they knew they had > > recursion in the design but didn't realize the fact that they didn't > > see the recursion in the call graphs was an error that should have > > been caught. > > The guys creating and viewing the call-graphs were not the designers of > the program, either, so they didn't know, but for sure it was something > they should have discovered and remarked on as part of their work. Do you know the intended purpose of the call graphs? It seems to me that it would be to match expectations to what was coded. It shouldn't matter who was doing the evaluation, there should have been an accounting of expectations regarding the presence and/or absence of recursion. Much like a check list, it doesn't just assure the presence of everything on the list, it can be used to verify the absence of anything not on the list. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2018-10-17 23:07 +0300 |
| Message-ID | <g2pj3hFdj2kU1@mid.individual.net> |
| In reply to | #28259 |
On 18-10-17 20:04 , gnuarm.deletethisbit@gmail.com wrote:
> On Wednesday, October 17, 2018 at 11:37:14 AM UTC-4, Niklas Holsti
> wrote:
>> On 18-10-17 17:08 , gnuarm.deletethisbit@gmail.com wrote:
>>> On Wednesday, October 17, 2018 at 2:35:46 AM UTC-4, Niklas
>>> Holsti wrote:
>>>> On 18-10-17 01:46 , David Brown wrote: ...
>>>>> When I am faced with someone else's code to examine or
>>>>> maintain, I often run it through Doxygen with "generate
>>>>> documentation for /everything/ - caller graphs, callee
>>>>> graphs, cross-linked source, etc." It can make it quick to
>>>>> jump around in the code. And recursive (or re-entrant,
>>>>> whichever you prefer) code stands out like a sore thumb, as
>>>>> long as the code is single-threaded - you get loops in the
>>>>> call graphs.
>>>>
>>>> Anecdote: some years ago, when I was applying a WCET analysis
>>>> tool to someone else's program, the tool found recursion. This
>>>> surprised the people I was working with, because they had
>>>> generated call graphs for the program, analysed them visually,
>>>> and found no recursive, looping paths.
>>>>
>>>> Turned out that they had asked the call-graph tool to optimize
>>>> the size of the window used to display the call-graphs. The
>>>> tool did as it was told, with the result that the line segments
>>>> on the path for the recursive call went down to the bottom edge
>>>> of the diagram, then *merged* with the lower border line of the
>>>> diagram, followed that lower border, went up one side of the
>>>> diagram -- still merged with the border line -- and then
>>>> reentered the diagram to point at the source of the recursive
>>>> call, effectively making the loop very hard to see...
>>>>
>>>> (It turned out that this recursion was intentional. At this
>>>> point, the program was sending an alarm message, but the alarm
>>>> buffer was full, so the alarm routine called itself to send an
>>>> alarm about the full buffer -- and that worked, because one
>>>> buffer slot was reserved, by design, for this "buffer full"
>>>> alarm.)
>>>
>>> Seems to me what actually failed was that they knew they had
>>> recursion in the design but didn't realize the fact that they
>>> didn't see the recursion in the call graphs was an error that
>>> should have been caught.
>>
>> The guys creating and viewing the call-graphs were not the
>> designers of the program, either, so they didn't know, but for sure
>> it was something they should have discovered and remarked on as
>> part of their work.
>
> Do you know the intended purpose of the call graphs?
IIRC they were doing independent SW verification & validation of the
program (and the WCET analysis was also a part of that). But it was many
years ago, and I don't remember the details well enough to say much
more, nor can I say why the program was recursive in this way, or if it
could as easily have been made non-recursive.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-17 08:23 +0200 |
| Message-ID | <pq6kht$iel$1@solani.org> |
| In reply to | #28245 |
Am 16.10.2018 um 22:52 schrieb Hans-Bernhard Bröker: > > Without recursion, one > would only really need reentrance to be able to call the same function > from separate threads of execution. On controllers this small, that > would only happen if you're calling the same function from inside an > interrupt handler and the main loop. And frankly: you really don't want > to do that. If an ISR on this kind of hardware becomes big enough you > feel the need to split it into sub-functions, that almost certainly > means you've picked entirely the wrong tool for the job. > > In other words: for this kind of system (very small, with rotten > stack-based addressing), not only doesn't everyone need re-entrant > functions, it's more like nobody does. Multithreading matters here. It is not common on such small devices, but this one is an exception: Padauk sells multiple dual-core variants of this controller and one 8-core variant. And there is always the support functions the compilers tend to need on small systems (while I assume people would think twice before using an expensive division in an interrupt handler, the situation looks different for multithreading). > > I don't think anyone has ever seriously claimed SDCC to be anywhere near > the pinnacle of compiler design for the 8051. ;-P > > Frankly, just looking at statements in this thread has me thinking that > the usual suspects among commercial offerings from 20 years ago might > still run circles around it today. I don't know of a current comparison for the MCS-51. For MCS-51, I do not know of a good compiler comparison; I did some benchmarks a while ago (https://sourceforge.net/p/sdcc/mailman/message/36359114/), and SDCC still has a bit of catching-up to do. On the other hand, for the STM8, SDCC seems to be doing more than just okay: http://www.colecovision.eu/stm8/compilers.shtml Philipp
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-17 19:43 +0300 |
| Message-ID | <i2oesdtl8rejgp6531q5bt4678jsdimikt@4ax.com> |
| In reply to | #28252 |
On Wed, 17 Oct 2018 08:23:57 +0200, Philipp Klaus Krause <pkk@spth.de> wrote: >Am 16.10.2018 um 22:52 schrieb Hans-Bernhard Bröker: >> >> Without recursion, one >> would only really need reentrance to be able to call the same function >> from separate threads of execution. On controllers this small, that >> would only happen if you're calling the same function from inside an >> interrupt handler and the main loop. And frankly: you really don't want >> to do that. If an ISR on this kind of hardware becomes big enough you >> feel the need to split it into sub-functions, that almost certainly >> means you've picked entirely the wrong tool for the job. >> >> In other words: for this kind of system (very small, with rotten >> stack-based addressing), not only doesn't everyone need re-entrant >> functions, it's more like nobody does. > >Multithreading matters here. It is not common on such small devices, but >this one is an exception: Padauk sells multiple dual-core variants of >this controller and one 8-core variant. While I have been playing around with the idea of making some RTOS for such 1kW/64B machine (realistically supporting 2-3 tasks such as a foregroud/bacground monitor) realistically having 2 or 8 thread is no very realistic, even if the hardware supports it. The 8 core version might be usable for xCore style "pseudo-interupts" running a single DSP sample or PLC loop at a time. This would require 8 input pins, each starting its own thread. But of course, the same rules should apply to pseudo-interrupts as real interrupts regarding re-entrancy etc.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-17 20:24 +0200 |
| Message-ID | <pq7uou$fl9$1@solani.org> |
| In reply to | #28258 |
Am 17.10.2018 um 18:43 schrieb upsidedown@downunder.com: > > While I have been playing around with the idea of making some RTOS for > such 1kW/64B machine (realistically supporting 2-3 tasks such as a > foregroud/bacground monitor) realistically having 2 or 8 thread is no > very realistic, even if the hardware supports it. > > The 8 core version might be usable for xCore style "pseudo-interupts" > running a single DSP sample or PLC loop at a time. This would require > 8 input pins, each starting its own thread. > > But of course, the same rules should apply to pseudo-interrupts as > real interrupts regarding re-entrancy etc. > Since the Padauk doesn't have much in term of integrated peripherals, there is another use for hardware threads: Have each thread do some I/O protocol (I²C, UART, etc) in software. Philipp
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web