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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2018-10-17 11:31 -0400 |
| Message-ID | <5tkesdpfojuvua5golst6t9vevcvkigqaf@4ax.com> |
| In reply to | #28245 |
On Tue, 16 Oct 2018 22:52:37 +0200, Hans-Bernhard Bröker <HBBroeker@t-online.de> wrote: >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. Recursion simply is a particlar useage of re-entrance: a function calling itself (possibly indirectly through other functions). You can use re-entrant functions without using recursion, but you can't recurse without re-entrant functions. Of course, re-entrance doesn't depend on a CPU stack ... it requires only that the local variables of each instance be kept separate. That can be done with auxiliary data structures. [It's interesting to watch programming students reinvent recursion - accidentally, or as an exercise - and realize all the effort saved by having it built into the language.] George
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-11-05 12:41 +0100 |
| Message-ID | <prpa97$udb$1@solani.org> |
| In reply to | #28187 |
Am 12.10.2018 um 09:44 schrieb David Brown: > On 12/10/18 08:50, Philipp Klaus Krause wrote: >> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>> upsidedown@downunder.com writes: >>>> There is a lot of operations that will update memory locations, so why >>>> would you need a lot of CPU registers. >>> >>> Being able to (say) add register to register saves traffic through the >>> accumulator and therefore instructions. >>> >>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >>>> assembly program listing. >>> >>> It would be nice to have a C compiler, and registers help with that. >>> >> >> Looking at the instruction set, it should be possible to make a backend >> for this in SDCC; the architecture looks more C-friendly than the >> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 >> or z80. >> reentrant functions will be inefficent: No registers, and no sp-relative >> adressing mode. On would want to reserve a few memory locations as >> pseudo-registers to help with that, but that only goes so far. >> > > It looks like the lowest 16 memory addresses could be considered > pseudo-registers - they are the ones that can be used for direct memory > access rather than needing indirect access. > Considering the multi-core variants of the Padauk µCs: Those adresses are shared across all cores. Each core only has its own A, SP, F, PC. How do we handle local variables? Option 1: Make functions non-reentrant. Requires duplication of code (we need per-thread copies of functions), and link-time analysis to ensure that each thread only calls the function implementation meant for it. Functions pointers get complicated. Option 2: Use an inefficient combination of thread-local storage and stack. Since this is a small µC, we need a lot of support functions, which the compiler inserts (e.g. for multiplication); of course those are affected by the same problems. Philipp
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-12 09:11 -0700 |
| Message-ID | <db074a68-df45-4b56-8ae4-80ebc451eaeb@googlegroups.com> |
| In reply to | #28186 |
On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote: > Am 12.10.2018 um 01:08 schrieb Paul Rubin: > > upsidedown@downunder.com writes: > >> There is a lot of operations that will update memory locations, so why > >> would you need a lot of CPU registers. > > > > Being able to (say) add register to register saves traffic through the > > accumulator and therefore instructions. > > > >> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented > >> assembly program listing. > > > > It would be nice to have a C compiler, and registers help with that. > > > > Looking at the instruction set, it should be possible to make a backend > for this in SDCC; the architecture looks more C-friendly than the > existing pic14 and pic16 backends. But it surely isn't as nice as stm8 > or z80. > reentrant functions will be inefficent: No registers, and no sp-relative > adressing mode. On would want to reserve a few memory locations as > pseudo-registers to help with that, but that only goes so far. CPUs like this (and others that aren't like this) should be programmed in Forth. It's a great tool for small MCUs and many times can be hosted on the target although not likely in this case. Still, you can bring enough functionality onto the MCU to allow direct downloads and many debugging features without an ICE. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-13 12:46 +0200 |
| Message-ID | <ppsido$59m$1@dont-email.me> |
| In reply to | #28189 |
On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: > On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote: >> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>> upsidedown@downunder.com writes: >>>> There is a lot of operations that will update memory locations, so why >>>> would you need a lot of CPU registers. >>> >>> Being able to (say) add register to register saves traffic through the >>> accumulator and therefore instructions. >>> >>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >>>> assembly program listing. >>> >>> It would be nice to have a C compiler, and registers help with that. >>> >> >> Looking at the instruction set, it should be possible to make a backend >> for this in SDCC; the architecture looks more C-friendly than the >> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 >> or z80. >> reentrant functions will be inefficent: No registers, and no sp-relative >> adressing mode. On would want to reserve a few memory locations as >> pseudo-registers to help with that, but that only goes so far. > > CPUs like this (and others that aren't like this) should be > programmed in Forth. It's a great tool for small MCUs and many times can be hosted > on the target although not likely in this case. Still, you can bring > enough functionality onto the MCU to allow direct downloads and many > debugging features without an ICE. > > Rick C. > Forth is a good language for very small devices, but there are details that can make a huge difference in how efficient it is. To make Forth work well on a small chip you need a Forth-specific instruction set to target the stack processing. For example, adding two numbers in this chip is two instructions - load accumulator from memory X, add accumulator to memory Y. In a Forth cpu, you'd have a single instruction that does "pop two numbers, add them, push the result". That gives a very efficient and compact instruction set. But it is hard to get the same results from a chip that doesn't have this kind of stack-based instruction set.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-13 05:06 -0700 |
| Message-ID | <7205434a-abd7-4b95-b4c7-d25d90cc6071@googlegroups.com> |
| In reply to | #28195 |
On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown wrote: > On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: > > On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote: > >> Am 12.10.2018 um 01:08 schrieb Paul Rubin: > >>> upsidedown@downunder.com writes: > >>>> There is a lot of operations that will update memory locations, so why > >>>> would you need a lot of CPU registers. > >>> > >>> Being able to (say) add register to register saves traffic through the > >>> accumulator and therefore instructions. > >>> > >>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented > >>>> assembly program listing. > >>> > >>> It would be nice to have a C compiler, and registers help with that. > >>> > >> > >> Looking at the instruction set, it should be possible to make a backend > >> for this in SDCC; the architecture looks more C-friendly than the > >> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 > >> or z80. > >> reentrant functions will be inefficent: No registers, and no sp-relative > >> adressing mode. On would want to reserve a few memory locations as > >> pseudo-registers to help with that, but that only goes so far. > > > > CPUs like this (and others that aren't like this) should be > > programmed in Forth. It's a great tool for small MCUs and many times can be hosted > > on the target although not likely in this case. Still, you can bring > > enough functionality onto the MCU to allow direct downloads and many > > debugging features without an ICE. > > > > Rick C. > > > > Forth is a good language for very small devices, but there are details > that can make a huge difference in how efficient it is. To make Forth > work well on a small chip you need a Forth-specific instruction set to > target the stack processing. For example, adding two numbers in this > chip is two instructions - load accumulator from memory X, add > accumulator to memory Y. In a Forth cpu, you'd have a single > instruction that does "pop two numbers, add them, push the result". > That gives a very efficient and compact instruction set. But it is hard > to get the same results from a chip that doesn't have this kind of > stack-based instruction set. Your point is what exactly? You are comparing running forth on some other chip to running forth on this chip. How is that useful? There are many other chips that run very fast. So? I believe others have said the instruction set is memory oriented with no registers. I think that means in general the CPU will be slow compared to a register based design. That actually means it is easier to have a fast Forth implementation compared to other compilers since there won't be a significant penalty for using a stack. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-13 18:00 +0300 |
| Message-ID | <tf04sdt3sapu3t7vgli6ofbr9okpa9793g@4ax.com> |
| In reply to | #28196 |
On Sat, 13 Oct 2018 05:06:23 -0700 (PDT), gnuarm.deletethisbit@gmail.com wrote: >On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown wrote: >> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: >> > On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote: >> >> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >> >>> upsidedown@downunder.com writes: >> >>>> There is a lot of operations that will update memory locations, so why >> >>>> would you need a lot of CPU registers. >> >>> >> >>> Being able to (say) add register to register saves traffic through the >> >>> accumulator and therefore instructions. >> >>> >> >>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >> >>>> assembly program listing. >> >>> >> >>> It would be nice to have a C compiler, and registers help with that. >> >>> >> >> >> >> Looking at the instruction set, it should be possible to make a backend >> >> for this in SDCC; the architecture looks more C-friendly than the >> >> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 >> >> or z80. >> >> reentrant functions will be inefficent: No registers, and no sp-relative >> >> adressing mode. On would want to reserve a few memory locations as >> >> pseudo-registers to help with that, but that only goes so far. >> > >> > CPUs like this (and others that aren't like this) should be >> > programmed in Forth. It's a great tool for small MCUs and many times can be hosted >> > on the target although not likely in this case. Still, you can bring >> > enough functionality onto the MCU to allow direct downloads and many >> > debugging features without an ICE. >> > >> > Rick C. >> > >> >> Forth is a good language for very small devices, but there are details >> that can make a huge difference in how efficient it is. To make Forth >> work well on a small chip you need a Forth-specific instruction set to >> target the stack processing. For example, adding two numbers in this >> chip is two instructions - load accumulator from memory X, add >> accumulator to memory Y. In a Forth cpu, you'd have a single >> instruction that does "pop two numbers, add them, push the result". >> That gives a very efficient and compact instruction set. But it is hard >> to get the same results from a chip that doesn't have this kind of >> stack-based instruction set. > >Your point is what exactly? You are comparing running forth on some other chip to running forth on this chip. How is that useful? There are many other chips that run very fast. So? > >I believe others have said the instruction set is memory oriented with no registers. Depending how you look at it, you could claim that it has 64 registers and no RAM. It is a quite orthogonal single address architecture. You can do practically all single operand instructions (like inc/dec, shift/rotate etc.) either in the accumulator but equally well in any of the 64 "registers". For two operand instructions (such as add/sub, and/or etc,), either the source or destination can be in the memory "register". Both Acc = Acc Op Memory or alternatively Memory = Acc Op Memory are valid. Thus the accumulator is needed only for two operand instructions, but not for single operand instructions. >I think that means in general the CPU will be slow compared to a register based design. What is the difference, you have 64 on chip RAM bytes or 64 single byte on chip registers. The situation would have been different with on-chip registers and off chip RAM, with the memory bottleneck. Of course, there were odd architectures like the TI 9900 with a set of sixteen 16 bit general purpose register in RAN. The set could be switched fast in interrupts, but slowed down any general purpose register access. >That actually means it is easier to have a fast Forth implementation compared to other compilers since there won't be a significant penalty for using a stack. For a stack computer you need a pointer register with preferably autoincrement/decrement support. This processor has indirect access and single instruction increment or decrement support without disturbing the accumulator.Thus not so bad after all for stack computing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-13 18:27 +0200 |
| Message-ID | <ppt6d2$jeu$1@dont-email.me> |
| In reply to | #28197 |
On 13/10/18 17:00, upsidedown@downunder.com wrote: > On Sat, 13 Oct 2018 05:06:23 -0700 (PDT), > gnuarm.deletethisbit@gmail.com wrote: > >> On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown wrote: >>> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: >>>> On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote: >>>>> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>>>>> upsidedown@downunder.com writes: >>>>>>> There is a lot of operations that will update memory locations, so why >>>>>>> would you need a lot of CPU registers. >>>>>> >>>>>> Being able to (say) add register to register saves traffic through the >>>>>> accumulator and therefore instructions. >>>>>> >>>>>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >>>>>>> assembly program listing. >>>>>> >>>>>> It would be nice to have a C compiler, and registers help with that. >>>>>> >>>>> >>>>> Looking at the instruction set, it should be possible to make a backend >>>>> for this in SDCC; the architecture looks more C-friendly than the >>>>> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 >>>>> or z80. >>>>> reentrant functions will be inefficent: No registers, and no sp-relative >>>>> adressing mode. On would want to reserve a few memory locations as >>>>> pseudo-registers to help with that, but that only goes so far. >>>> >>>> CPUs like this (and others that aren't like this) should be >>>> programmed in Forth. It's a great tool for small MCUs and many times can be hosted >>>> on the target although not likely in this case. Still, you can bring >>>> enough functionality onto the MCU to allow direct downloads and many >>>> debugging features without an ICE. >>>> >>>> Rick C. >>>> >>> >>> Forth is a good language for very small devices, but there are details >>> that can make a huge difference in how efficient it is. To make Forth >>> work well on a small chip you need a Forth-specific instruction set to >>> target the stack processing. For example, adding two numbers in this >>> chip is two instructions - load accumulator from memory X, add >>> accumulator to memory Y. In a Forth cpu, you'd have a single >>> instruction that does "pop two numbers, add them, push the result". >>> That gives a very efficient and compact instruction set. But it is hard >>> to get the same results from a chip that doesn't have this kind of >>> stack-based instruction set. >> >> Your point is what exactly? You are comparing running forth on some other chip to running forth on this chip. How is that useful? There are many other chips that run very fast. So? >> >> I believe others have said the instruction set is memory oriented with no registers. > > Depending how you look at it, you could claim that it has 64 registers > and no RAM. It is a quite orthogonal single address architecture. You > can do practically all single operand instructions (like inc/dec, > shift/rotate etc.) either in the accumulator but equally well in any > of the 64 "registers". For two operand instructions (such as add/sub, > and/or etc,), either the source or destination can be in the memory > "register". Not quite, no. Only the first 16 memory addresses are directly accessible for most instructions, with the first 32 addresses being available for word-based instructions. So you could liken it to a device with 16 registers and indirect memory access to the rest of ram. > > Both Acc = Acc Op Memory or alternatively Memory = Acc Op Memory are > valid. > > Thus the accumulator is needed only for two operand instructions, but > not for single operand instructions. > >> I think that means in general the CPU will be slow compared to a register based design. > > What is the difference, you have 64 on chip RAM bytes or 64 single > byte on chip registers. The situation would have been different with > on-chip registers and off chip RAM, with the memory bottleneck. > > Of course, there were odd architectures like the TI 9900 with a set of > sixteen 16 bit general purpose register in RAN. The set could be > switched fast in interrupts, but slowed down any general purpose > register access. > >> That actually means it is easier to have a fast Forth implementation compared to other compilers since there won't be a significant penalty for using a stack. > > For a stack computer you need a pointer register with preferably > autoincrement/decrement support. This processor has indirect access > and single instruction increment or decrement support without > disturbing the accumulator.Thus not so bad after all for stack > computing. > But you can't use the indirect memory accesses for any ALU instructions - only for loading or saving the accumulator. So all indirect accesses need to go via the accumulator - and if you want to operate on two indirect accesses (like adding the top two elements on the stack), you have to use another "register" address to store one element temporarily. Yes, it would be bad for stack computing.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-13 20:50 +0300 |
| Message-ID | <l0b4sdtgj97u0l23d9f2dj24tap24eojse@4ax.com> |
| In reply to | #28200 |
On Sat, 13 Oct 2018 18:27:13 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 13/10/18 17:00, upsidedown@downunder.com wrote: >> On Sat, 13 Oct 2018 05:06:23 -0700 (PDT), >> gnuarm.deletethisbit@gmail.com wrote: >> >>> On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown wrote: >>>> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: >>>>> On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote: >>>>>> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>>>>>> upsidedown@downunder.com writes: >>>>>>>> There is a lot of operations that will update memory locations, so why >>>>>>>> would you need a lot of CPU registers. >>>>>>> >>>>>>> Being able to (say) add register to register saves traffic through the >>>>>>> accumulator and therefore instructions. >>>>>>> >>>>>>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >>>>>>>> assembly program listing. >>>>>>> >>>>>>> It would be nice to have a C compiler, and registers help with that. >>>>>>> >>>>>> >>>>>> Looking at the instruction set, it should be possible to make a backend >>>>>> for this in SDCC; the architecture looks more C-friendly than the >>>>>> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 >>>>>> or z80. >>>>>> reentrant functions will be inefficent: No registers, and no sp-relative >>>>>> adressing mode. On would want to reserve a few memory locations as >>>>>> pseudo-registers to help with that, but that only goes so far. >>>>> >>>>> CPUs like this (and others that aren't like this) should be >>>>> programmed in Forth. It's a great tool for small MCUs and many times can be hosted >>>>> on the target although not likely in this case. Still, you can bring >>>>> enough functionality onto the MCU to allow direct downloads and many >>>>> debugging features without an ICE. >>>>> >>>>> Rick C. >>>>> >>>> >>>> Forth is a good language for very small devices, but there are details >>>> that can make a huge difference in how efficient it is. To make Forth >>>> work well on a small chip you need a Forth-specific instruction set to >>>> target the stack processing. For example, adding two numbers in this >>>> chip is two instructions - load accumulator from memory X, add >>>> accumulator to memory Y. In a Forth cpu, you'd have a single >>>> instruction that does "pop two numbers, add them, push the result". >>>> That gives a very efficient and compact instruction set. But it is hard >>>> to get the same results from a chip that doesn't have this kind of >>>> stack-based instruction set. >>> >>> Your point is what exactly? You are comparing running forth on some other chip to running forth on this chip. How is that useful? There are many other chips that run very fast. So? >>> >>> I believe others have said the instruction set is memory oriented with no registers. >> >> Depending how you look at it, you could claim that it has 64 registers >> and no RAM. It is a quite orthogonal single address architecture. You >> can do practically all single operand instructions (like inc/dec, >> shift/rotate etc.) either in the accumulator but equally well in any >> of the 64 "registers". For two operand instructions (such as add/sub, >> and/or etc,), either the source or destination can be in the memory >> "register". > >Not quite, no. Only the first 16 memory addresses are directly >accessible for most instructions, with the first 32 addresses being >available for word-based instructions. So you could liken it to a >device with 16 registers and indirect memory access to the rest of ram. Really ? In the manual > M.n Only addressed in 0~0xF (0~15) is allowed The M.n notation is for bit operations, in which M is the byte address and n is the bit number in byte. Restricting M to 4 bits makes sense, since n requires 3 bits, thus the total address size for bit operations would be 7 bits. I couldn't find a reference that the restriction on M also applies to byte access. Where is it ?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-14 14:26 +0200 |
| Message-ID | <ppvcko$spt$1@dont-email.me> |
| In reply to | #28203 |
On 13/10/18 19:50, upsidedown@downunder.com wrote: > On Sat, 13 Oct 2018 18:27:13 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 13/10/18 17:00, upsidedown@downunder.com wrote: >>> On Sat, 13 Oct 2018 05:06:23 -0700 (PDT), >>> gnuarm.deletethisbit@gmail.com wrote: >>> >>>> On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown wrote: >>>>> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: >>>>>> On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote: >>>>>>> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>>>>>>> upsidedown@downunder.com writes: >>>>>>>>> There is a lot of operations that will update memory locations, so why >>>>>>>>> would you need a lot of CPU registers. >>>>>>>> >>>>>>>> Being able to (say) add register to register saves traffic through the >>>>>>>> accumulator and therefore instructions. >>>>>>>> >>>>>>>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented >>>>>>>>> assembly program listing. >>>>>>>> >>>>>>>> It would be nice to have a C compiler, and registers help with that. >>>>>>>> >>>>>>> >>>>>>> Looking at the instruction set, it should be possible to make a backend >>>>>>> for this in SDCC; the architecture looks more C-friendly than the >>>>>>> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 >>>>>>> or z80. >>>>>>> reentrant functions will be inefficent: No registers, and no sp-relative >>>>>>> adressing mode. On would want to reserve a few memory locations as >>>>>>> pseudo-registers to help with that, but that only goes so far. >>>>>> >>>>>> CPUs like this (and others that aren't like this) should be >>>>>> programmed in Forth. It's a great tool for small MCUs and many times can be hosted >>>>>> on the target although not likely in this case. Still, you can bring >>>>>> enough functionality onto the MCU to allow direct downloads and many >>>>>> debugging features without an ICE. >>>>>> >>>>>> Rick C. >>>>>> >>>>> >>>>> Forth is a good language for very small devices, but there are details >>>>> that can make a huge difference in how efficient it is. To make Forth >>>>> work well on a small chip you need a Forth-specific instruction set to >>>>> target the stack processing. For example, adding two numbers in this >>>>> chip is two instructions - load accumulator from memory X, add >>>>> accumulator to memory Y. In a Forth cpu, you'd have a single >>>>> instruction that does "pop two numbers, add them, push the result". >>>>> That gives a very efficient and compact instruction set. But it is hard >>>>> to get the same results from a chip that doesn't have this kind of >>>>> stack-based instruction set. >>>> >>>> Your point is what exactly? You are comparing running forth on some other chip to running forth on this chip. How is that useful? There are many other chips that run very fast. So? >>>> >>>> I believe others have said the instruction set is memory oriented with no registers. >>> >>> Depending how you look at it, you could claim that it has 64 registers >>> and no RAM. It is a quite orthogonal single address architecture. You >>> can do practically all single operand instructions (like inc/dec, >>> shift/rotate etc.) either in the accumulator but equally well in any >>> of the 64 "registers". For two operand instructions (such as add/sub, >>> and/or etc,), either the source or destination can be in the memory >>> "register". >> >> Not quite, no. Only the first 16 memory addresses are directly >> accessible for most instructions, with the first 32 addresses being >> available for word-based instructions. So you could liken it to a >> device with 16 registers and indirect memory access to the rest of ram. > > Really ? > > In the manual > >> M.n Only addressed in 0~0xF (0~15) is allowed > > The M.n notation is for bit operations, in which M is the byte address > and n is the bit number in byte. Restricting M to 4 bits makes sense, > since n requires 3 bits, thus the total address size for bit > operations would be 7 bits. > > I couldn't find a reference that the restriction on M also applies to > byte access. Where is it ? > My interpretation of the manual was that you only had access to the first 16 addresses with the M instructions. But it is entirely possible that I am wrong and your interpretation is right. I haven't tried the devices, or the IDE, and the manual does not have details of things like instruction format. Certainly it would be nicer for the chip if you are right!
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-13 18:20 -0700 |
| Message-ID | <817bef86-b326-4a00-bc29-21ba0fdec587@googlegroups.com> |
| In reply to | #28197 |
On Saturday, October 13, 2018 at 11:00:30 AM UTC-4, upsid...@downunder.com wrote: > On Sat, 13 Oct 2018 05:06:23 -0700 (PDT), > gnuarm.deletethisbit@gmail.com wrote: > > >On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown wrote: > >> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: > >> > On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote: > >> >> Am 12.10.2018 um 01:08 schrieb Paul Rubin: > >> >>> upsidedown@downunder.com writes: > >> >>>> There is a lot of operations that will update memory locations, so why > >> >>>> would you need a lot of CPU registers. > >> >>> > >> >>> Being able to (say) add register to register saves traffic through the > >> >>> accumulator and therefore instructions. > >> >>> > >> >>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented > >> >>>> assembly program listing. > >> >>> > >> >>> It would be nice to have a C compiler, and registers help with that. > >> >>> > >> >> > >> >> Looking at the instruction set, it should be possible to make a backend > >> >> for this in SDCC; the architecture looks more C-friendly than the > >> >> existing pic14 and pic16 backends. But it surely isn't as nice as stm8 > >> >> or z80. > >> >> reentrant functions will be inefficent: No registers, and no sp-relative > >> >> adressing mode. On would want to reserve a few memory locations as > >> >> pseudo-registers to help with that, but that only goes so far. > >> > > >> > CPUs like this (and others that aren't like this) should be > >> > programmed in Forth. It's a great tool for small MCUs and many times can be hosted > >> > on the target although not likely in this case. Still, you can bring > >> > enough functionality onto the MCU to allow direct downloads and many > >> > debugging features without an ICE. > >> > > >> > Rick C. > >> > > >> > >> Forth is a good language for very small devices, but there are details > >> that can make a huge difference in how efficient it is. To make Forth > >> work well on a small chip you need a Forth-specific instruction set to > >> target the stack processing. For example, adding two numbers in this > >> chip is two instructions - load accumulator from memory X, add > >> accumulator to memory Y. In a Forth cpu, you'd have a single > >> instruction that does "pop two numbers, add them, push the result". > >> That gives a very efficient and compact instruction set. But it is hard > >> to get the same results from a chip that doesn't have this kind of > >> stack-based instruction set. > > > >Your point is what exactly? You are comparing running forth on some other chip to running forth on this chip. How is that useful? There are many other chips that run very fast. So? > > > >I believe others have said the instruction set is memory oriented with no registers. > > Depending how you look at it, you could claim that it has 64 registers > and no RAM. It is a quite orthogonal single address architecture. You > can do practically all single operand instructions (like inc/dec, > shift/rotate etc.) either in the accumulator but equally well in any > of the 64 "registers". For two operand instructions (such as add/sub, > and/or etc,), either the source or destination can be in the memory > "register". > > Both Acc = Acc Op Memory or alternatively Memory = Acc Op Memory are > valid. > > Thus the accumulator is needed only for two operand instructions, but > not for single operand instructions. How fast are instructions that access memory? Most MCUs will perform register operations in a single cycle. Even though RAM may be on chip, it typically is not as fast as registers because it is usually not multiported. DSP chips are an exception with dual and even triple ported on chip RAM. > >I think that means in general the CPU will be slow compared to a register based design. > > What is the difference, you have 64 on chip RAM bytes or 64 single > byte on chip registers. The situation would have been different with > on-chip registers and off chip RAM, with the memory bottleneck. > > Of course, there were odd architectures like the TI 9900 with a set of > sixteen 16 bit general purpose register in RAN. The set could be > switched fast in interrupts, but slowed down any general purpose > register access. Yeah, I'm familiar with the 9900. In the 990 it worked well because the CPU was TTL and not so fast. Once the CPU was on a single chip the external RAM was not fast enough to keep up really and instruction timings were dominated by the memory. > >That actually means it is easier to have a fast Forth implementation compared to other compilers since there won't be a significant penalty for using a stack. > > For a stack computer you need a pointer register with preferably > autoincrement/decrement support. This processor has indirect access > and single instruction increment or decrement support without > disturbing the accumulator.Thus not so bad after all for stack > computing. The stack in memory is usually a bottle neck because memory is typically slow so optimizations would be done to keep operands in registers. In this chip no optimizations are possible, but likely it wouldn't be too bad as long as the stack operations are flexible enough. But then I don't think you said this CPU has the sort of addressing that allows an operand in memory to be used and popped off the stack in one opcode as many, higher level CPUs do. So adding the two numbers on the stack would involve keeping the top of stack in the accumulator, adding the next item on the stack from memory to the accumulator, then another instruction to adjust the stack pointer which is also in memory. So two instructions? How many clock cycles? What happens when there is a change in the instruction pointer of the Forth virtual machine? Calling a new word would require saving the current value of the Forth IP on the return stack (separate from the data stack) and loading a new value into the Forth IP? This is a piece of code typically called "next". It varies a bit between indirect and direct threaded code. Then there is subroutine threaded code that just uses the CPU IP as the Forth IP and each address is actually a CPU call instruction. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-14 08:53 +0200 |
| Message-ID | <ppup4r$b0o$1@solani.org> |
| In reply to | #28213 |
Am 14.10.2018 um 03:20 schrieb gnuarm.deletethisbit@gmail.com: > > How fast are instructions that access memory? Most MCUs will perform > register operations in a single cycle. Even though RAM may be on > chip, it typically is not as fast as registers because it is usually > not multiported. DSP chips are an exception with dual and even > triple ported on chip RAM. All instructions except for jumps are 1 cycle. Jumps if taken are 2 cycles, 1 otherwise. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-14 08:55 +0200 |
| Message-ID | <ppup8q$b0o$2@solani.org> |
| In reply to | #28217 |
Am 14.10.2018 um 08:53 schrieb Philipp Klaus Krause: > Am 14.10.2018 um 03:20 schrieb gnuarm.deletethisbit@gmail.com: >> >> How fast are instructions that access memory? Most MCUs will perform >> register operations in a single cycle. Even though RAM may be on >> chip, it typically is not as fast as registers because it is usually >> not multiported. DSP chips are an exception with dual and even >> triple ported on chip RAM. > > All instructions except for jumps are 1 cycle. Jumps if taken are 2 > cycles, 1 otherwise. > > Philipp > idxm and ldxm seem to be 2 cycles, too. Philipp
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-14 14:32 +0200 |
| Message-ID | <ppvd11$v0t$1@dont-email.me> |
| In reply to | #28213 |
On 14/10/18 03:20, gnuarm.deletethisbit@gmail.com wrote: > On Saturday, October 13, 2018 at 11:00:30 AM UTC-4, > upsid...@downunder.com wrote: >> On Sat, 13 Oct 2018 05:06:23 -0700 (PDT), >> gnuarm.deletethisbit@gmail.com wrote: >> >>> On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown >>> wrote: >>>> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: >>>>> On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp >>>>> Klaus Krause wrote: >>>>>> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>>>>>> upsidedown@downunder.com writes: >>>>>>>> There is a lot of operations that will update memory >>>>>>>> locations, so why would you need a lot of CPU >>>>>>>> registers. >>>>>>> >>>>>>> Being able to (say) add register to register saves >>>>>>> traffic through the accumulator and therefore >>>>>>> instructions. >>>>>>> >>>>>>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages >>>>>>>> of commented assembly program listing. >>>>>>> >>>>>>> It would be nice to have a C compiler, and registers help >>>>>>> with that. >>>>>>> >>>>>> >>>>>> Looking at the instruction set, it should be possible to >>>>>> make a backend for this in SDCC; the architecture looks >>>>>> more C-friendly than the existing pic14 and pic16 backends. >>>>>> But it surely isn't as nice as stm8 or z80. reentrant >>>>>> functions will be inefficent: No registers, and no >>>>>> sp-relative adressing mode. On would want to reserve a few >>>>>> memory locations as pseudo-registers to help with that, but >>>>>> that only goes so far. >>>>> >>>>> CPUs like this (and others that aren't like this) should be >>>>> programmed in Forth. It's a great tool for small MCUs and >>>>> many times can be hosted on the target although not likely in >>>>> this case. Still, you can bring enough functionality onto the >>>>> MCU to allow direct downloads and many debugging features >>>>> without an ICE. >>>>> >>>>> Rick C. >>>>> >>>> >>>> Forth is a good language for very small devices, but there are >>>> details that can make a huge difference in how efficient it is. >>>> To make Forth work well on a small chip you need a >>>> Forth-specific instruction set to target the stack processing. >>>> For example, adding two numbers in this chip is two >>>> instructions - load accumulator from memory X, add accumulator >>>> to memory Y. In a Forth cpu, you'd have a single instruction >>>> that does "pop two numbers, add them, push the result". That >>>> gives a very efficient and compact instruction set. But it is >>>> hard to get the same results from a chip that doesn't have this >>>> kind of stack-based instruction set. >>> >>> Your point is what exactly? You are comparing running forth on >>> some other chip to running forth on this chip. How is that >>> useful? There are many other chips that run very fast. So? >>> >>> I believe others have said the instruction set is memory oriented >>> with no registers. >> >> Depending how you look at it, you could claim that it has 64 >> registers and no RAM. It is a quite orthogonal single address >> architecture. You can do practically all single operand >> instructions (like inc/dec, shift/rotate etc.) either in the >> accumulator but equally well in any of the 64 "registers". For two >> operand instructions (such as add/sub, and/or etc,), either the >> source or destination can be in the memory "register". >> >> Both Acc = Acc Op Memory or alternatively Memory = Acc Op Memory >> are valid. >> >> Thus the accumulator is needed only for two operand instructions, >> but not for single operand instructions. > > How fast are instructions that access memory? Most MCUs will perform > register operations in a single cycle. Even though RAM may be on > chip, it typically is not as fast as registers because it is usually > not multiported. DSP chips are an exception with dual and even > triple ported on chip RAM. Single cycle, according to the manual. Instructions involving 16-bit values are two cycle, the conditional branch instructions may be one or two cycles, and everything else is one cycle. It is not so hard to make the RAM dual ported when there is only 64 bytes of it. Or perhaps the core is clocked on both falling and rising edges, so that the instructions are effectively 2/4 clocks rather than 1 or two. We can only guess.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-13 18:21 +0200 |
| Message-ID | <ppt62r$daj$1@dont-email.me> |
| In reply to | #28196 |
On 13/10/18 14:06, gnuarm.deletethisbit@gmail.com wrote: > On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown > wrote: >> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: >>> On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus >>> Krause wrote: >>>> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>>>> upsidedown@downunder.com writes: >>>>>> There is a lot of operations that will update memory >>>>>> locations, so why would you need a lot of CPU registers. >>>>> >>>>> Being able to (say) add register to register saves traffic >>>>> through the accumulator and therefore instructions. >>>>> >>>>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of >>>>>> commented assembly program listing. >>>>> >>>>> It would be nice to have a C compiler, and registers help >>>>> with that. >>>>> >>>> >>>> Looking at the instruction set, it should be possible to make a >>>> backend for this in SDCC; the architecture looks more >>>> C-friendly than the existing pic14 and pic16 backends. But it >>>> surely isn't as nice as stm8 or z80. reentrant functions will >>>> be inefficent: No registers, and no sp-relative adressing mode. >>>> On would want to reserve a few memory locations as >>>> pseudo-registers to help with that, but that only goes so far. >>> >>> CPUs like this (and others that aren't like this) should be >>> programmed in Forth. It's a great tool for small MCUs and many >>> times can be hosted on the target although not likely in this >>> case. Still, you can bring enough functionality onto the MCU to >>> allow direct downloads and many debugging features without an >>> ICE. >>> >>> Rick C. >>> >> >> Forth is a good language for very small devices, but there are >> details that can make a huge difference in how efficient it is. To >> make Forth work well on a small chip you need a Forth-specific >> instruction set to target the stack processing. For example, >> adding two numbers in this chip is two instructions - load >> accumulator from memory X, add accumulator to memory Y. In a Forth >> cpu, you'd have a single instruction that does "pop two numbers, >> add them, push the result". That gives a very efficient and compact >> instruction set. But it is hard to get the same results from a >> chip that doesn't have this kind of stack-based instruction set. > > Your point is what exactly? You are comparing running forth on some > other chip to running forth on this chip. How is that useful? There > are many other chips that run very fast. So? My point is that /this/ CPU is not a good match for Forth, though many other very cheap CPUs are. Whether or not you think that matches "CPUs like this should be programmed in Forth" depends on what you mean by "CPUs like this", and what you think the benefits of Forth are. > > I believe others have said the instruction set is memory oriented > with no registers. I think that means in general the CPU will be > slow compared to a register based design. That actually means it is > easier to have a fast Forth implementation compared to other > compilers since there won't be a significant penalty for using a > stack. > It has a single register, not unlike the "W" register in small PIC devices. Yes, I expect it is going to be slower than you would get from having a few more registers. But it is missing (AFAICS) auto-increment and decrement modes, and has only load/store operations with indirect access. So if you have two 8-bit bytes x and y, then adding them as "x += y;" is: mov a, y; // 1 clock add x, a; // 1 clock If you have a data stack pointer "dsp", and want a standard Forth "+" operation, you have: idxm a, dsp; // 2 clock mov temp, a; // 1 clock dec dsp; // 1 clock idxm a, dsp; // 2 clock add a, temp; // 1 clock idxm dsp, a; // 2 clock That is 9 clocks, instead of 2, and 6 instructions instead of 3. Of course you could make a Forth compiler for the device - but you would have to make an optimising Forth compiler that avoids needing a data stack, just as you do on many other small microcontollers (and just as a C compiler would do). This is /not/ a processor that fits well with Forth or that would give a clear translation from Forth to assembly, as is the case on some very small microcontrollers.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-13 18:32 -0700 |
| Message-ID | <6a3fffa2-6190-4b37-ad81-88ad2bb7b218@googlegroups.com> |
| In reply to | #28199 |
On Saturday, October 13, 2018 at 12:21:51 PM UTC-4, David Brown wrote: > On 13/10/18 14:06, gnuarm.deletethisbit@gmail.com wrote: > > On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown > > wrote: > >> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: > >>> On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus > >>> Krause wrote: > >>>> Am 12.10.2018 um 01:08 schrieb Paul Rubin: > >>>>> upsidedown@downunder.com writes: > >>>>>> There is a lot of operations that will update memory > >>>>>> locations, so why would you need a lot of CPU registers. > >>>>> > >>>>> Being able to (say) add register to register saves traffic > >>>>> through the accumulator and therefore instructions. > >>>>> > >>>>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of > >>>>>> commented assembly program listing. > >>>>> > >>>>> It would be nice to have a C compiler, and registers help > >>>>> with that. > >>>>> > >>>> > >>>> Looking at the instruction set, it should be possible to make a > >>>> backend for this in SDCC; the architecture looks more > >>>> C-friendly than the existing pic14 and pic16 backends. But it > >>>> surely isn't as nice as stm8 or z80. reentrant functions will > >>>> be inefficent: No registers, and no sp-relative adressing mode. > >>>> On would want to reserve a few memory locations as > >>>> pseudo-registers to help with that, but that only goes so far. > >>> > >>> CPUs like this (and others that aren't like this) should be > >>> programmed in Forth. It's a great tool for small MCUs and many > >>> times can be hosted on the target although not likely in this > >>> case. Still, you can bring enough functionality onto the MCU to > >>> allow direct downloads and many debugging features without an > >>> ICE. > >>> > >>> Rick C. > >>> > >> > >> Forth is a good language for very small devices, but there are > >> details that can make a huge difference in how efficient it is. To > >> make Forth work well on a small chip you need a Forth-specific > >> instruction set to target the stack processing. For example, > >> adding two numbers in this chip is two instructions - load > >> accumulator from memory X, add accumulator to memory Y. In a Forth > >> cpu, you'd have a single instruction that does "pop two numbers, > >> add them, push the result". That gives a very efficient and compact > >> instruction set. But it is hard to get the same results from a > >> chip that doesn't have this kind of stack-based instruction set. > > > > Your point is what exactly? You are comparing running forth on some > > other chip to running forth on this chip. How is that useful? There > > are many other chips that run very fast. So? > > My point is that /this/ CPU is not a good match for Forth, though many > other very cheap CPUs are. Whether or not you think that matches "CPUs > like this should be programmed in Forth" depends on what you mean by > "CPUs like this", and what you think the benefits of Forth are. > > > > > I believe others have said the instruction set is memory oriented > > with no registers. I think that means in general the CPU will be > > slow compared to a register based design. That actually means it is > > easier to have a fast Forth implementation compared to other > > compilers since there won't be a significant penalty for using a > > stack. > > > > It has a single register, not unlike the "W" register in small PIC > devices. Yes, I expect it is going to be slower than you would get from > having a few more registers. But it is missing (AFAICS) auto-increment > and decrement modes, and has only load/store operations with indirect > access. > > So if you have two 8-bit bytes x and y, then adding them as "x += y;" is: > > mov a, y; // 1 clock > add x, a; // 1 clock Keep the TOS in the accumulator and I think you end up with add a, x; // 1 clock inc DSTKPTR; // adjust stack pointer - 1 clock? Does that work? Reading below, I guess not. > If you have a data stack pointer "dsp", and want a standard Forth "+" > operation, you have: > > idxm a, dsp; // 2 clock > mov temp, a; // 1 clock > dec dsp; // 1 clock > idxm a, dsp; // 2 clock > add a, temp; // 1 clock > idxm dsp, a; // 2 clock > > That is 9 clocks, instead of 2, and 6 instructions instead of 3. What does idxm do? Looks like an indirect load? Can this address mode be combined with any operations? Are operations limited in the addressing modes? This seems like a very, very simple CPU, but for the money, I guess I get it. > Of course you could make a Forth compiler for the device - but you would > have to make an optimising Forth compiler that avoids needing a data > stack, just as you do on many other small microcontollers (and just as a > C compiler would do). This is /not/ a processor that fits well with > Forth or that would give a clear translation from Forth to assembly, as > is the case on some very small microcontrollers. OK Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2018-10-13 19:02 -0700 |
| Message-ID | <87bm7xmgjl.fsf@nightsong.com> |
| In reply to | #28215 |
gnuarm.deletethisbit@gmail.com writes: > Keep the TOS in the accumulator Do you mean you want a Forth with 8-bit data cells? What about the cells on the return stack, if there is one? > What does idxm do? Looks like an indirect load? Yes. > Can this address mode be combined with any operations? No. Just load or store.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-14 14:37 +0200 |
| Message-ID | <ppvd9i$ro$1@dont-email.me> |
| In reply to | #28215 |
On 14/10/18 03:32, gnuarm.deletethisbit@gmail.com wrote: > On Saturday, October 13, 2018 at 12:21:51 PM UTC-4, David Brown wrote: >> On 13/10/18 14:06, gnuarm.deletethisbit@gmail.com wrote: >>> On Saturday, October 13, 2018 at 6:46:20 AM UTC-4, David Brown >>> wrote: >>>> On 12/10/18 18:11, gnuarm.deletethisbit@gmail.com wrote: >>>>> On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus >>>>> Krause wrote: >>>>>> Am 12.10.2018 um 01:08 schrieb Paul Rubin: >>>>>>> upsidedown@downunder.com writes: >>>>>>>> There is a lot of operations that will update memory >>>>>>>> locations, so why would you need a lot of CPU registers. >>>>>>> >>>>>>> Being able to (say) add register to register saves traffic >>>>>>> through the accumulator and therefore instructions. >>>>>>> >>>>>>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of >>>>>>>> commented assembly program listing. >>>>>>> >>>>>>> It would be nice to have a C compiler, and registers help >>>>>>> with that. >>>>>>> >>>>>> >>>>>> Looking at the instruction set, it should be possible to make a >>>>>> backend for this in SDCC; the architecture looks more >>>>>> C-friendly than the existing pic14 and pic16 backends. But it >>>>>> surely isn't as nice as stm8 or z80. reentrant functions will >>>>>> be inefficent: No registers, and no sp-relative adressing mode. >>>>>> On would want to reserve a few memory locations as >>>>>> pseudo-registers to help with that, but that only goes so far. >>>>> >>>>> CPUs like this (and others that aren't like this) should be >>>>> programmed in Forth. It's a great tool for small MCUs and many >>>>> times can be hosted on the target although not likely in this >>>>> case. Still, you can bring enough functionality onto the MCU to >>>>> allow direct downloads and many debugging features without an >>>>> ICE. >>>>> >>>>> Rick C. >>>>> >>>> >>>> Forth is a good language for very small devices, but there are >>>> details that can make a huge difference in how efficient it is. To >>>> make Forth work well on a small chip you need a Forth-specific >>>> instruction set to target the stack processing. For example, >>>> adding two numbers in this chip is two instructions - load >>>> accumulator from memory X, add accumulator to memory Y. In a Forth >>>> cpu, you'd have a single instruction that does "pop two numbers, >>>> add them, push the result". That gives a very efficient and compact >>>> instruction set. But it is hard to get the same results from a >>>> chip that doesn't have this kind of stack-based instruction set. >>> >>> Your point is what exactly? You are comparing running forth on some >>> other chip to running forth on this chip. How is that useful? There >>> are many other chips that run very fast. So? >> >> My point is that /this/ CPU is not a good match for Forth, though many >> other very cheap CPUs are. Whether or not you think that matches "CPUs >> like this should be programmed in Forth" depends on what you mean by >> "CPUs like this", and what you think the benefits of Forth are. >> >>> >>> I believe others have said the instruction set is memory oriented >>> with no registers. I think that means in general the CPU will be >>> slow compared to a register based design. That actually means it is >>> easier to have a fast Forth implementation compared to other >>> compilers since there won't be a significant penalty for using a >>> stack. >>> >> >> It has a single register, not unlike the "W" register in small PIC >> devices. Yes, I expect it is going to be slower than you would get from >> having a few more registers. But it is missing (AFAICS) auto-increment >> and decrement modes, and has only load/store operations with indirect >> access. >> >> So if you have two 8-bit bytes x and y, then adding them as "x += y;" is: >> >> mov a, y; // 1 clock >> add x, a; // 1 clock > > Keep the TOS in the accumulator and I think you end up with > > add a, x; // 1 clock > inc DSTKPTR; // adjust stack pointer - 1 clock? > > Does that work? Reading below, I guess not. > > >> If you have a data stack pointer "dsp", and want a standard Forth "+" >> operation, you have: >> >> idxm a, dsp; // 2 clock >> mov temp, a; // 1 clock >> dec dsp; // 1 clock >> idxm a, dsp; // 2 clock >> add a, temp; // 1 clock >> idxm dsp, a; // 2 clock >> >> That is 9 clocks, instead of 2, and 6 instructions instead of 3. > > What does idxm do? Looks like an indirect load? Can this address > mode be combined with any operations? Are operations limited in the > addressing modes? This seems like a very, very simple CPU, but for the > money, I guess I get it. "idxm" is an indirect load or store (depending on the order of the operands). No, there are no other operations that can be combined with indirect accesses. If you want to keep the TOS in the accumulator, then Forth "+" becomes: mov temp, a; // 1 clock dec dsp; // 1 clock idxm a, dsp; // 2 clock add a, temp; // 1 clock 5 clocks is a good deal better than 9 clocks, but still a good deal worse than 2 clocks. > > >> Of course you could make a Forth compiler for the device - but you would >> have to make an optimising Forth compiler that avoids needing a data >> stack, just as you do on many other small microcontollers (and just as a >> C compiler would do). This is /not/ a processor that fits well with >> Forth or that would give a clear translation from Forth to assembly, as >> is the case on some very small microcontrollers. > > OK > A stack-based system is often a good choice for very small cpus - it is certainly popular for 4-bit microcontrollers. But it seems that the designers of this device simply haven't considered support for Forth-style coding to be important.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-14 14:59 +0200 |
| Message-ID | <ppvek4$qos$1@solani.org> |
| In reply to | #28224 |
Am 14.10.2018 um 14:37 schrieb David Brown: > > A stack-based system is often a good choice for very small cpus - it is > certainly popular for 4-bit microcontrollers. But it seems that the > designers of this device simply haven't considered support for > Forth-style coding to be important. Efficient stack acccess is important for C, too. Putting local variables on the stack makes functions reentrant (not so important for small devices), and also saves memory (bery important for small devices). The STM8 and S08 with their efficent sp-relative adressing and the Z80 with the index registers thus make better targets for C compilers than the MCS-51 and HC08. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2018-10-13 11:06 -0700 |
| Message-ID | <87sh19n2l6.fsf@nightsong.com> |
| In reply to | #28196 |
gnuarm.deletethisbit@gmail.com writes: > That actually means it is easier to have a fast Forth implementation > compared to other compilers since there won't be a significant penalty > for using a stack. I think this chip is too small for traditional Forth implementation methods. Just 64 bytes of ram and no registers. If you have 16 bit cells and 8 levels of return and data stacks, half the ram is already used by the stacks. An F18 processor (GA144 node for those not familiar) has around 3x as much ram including the stacks, and it doesn't pretend to be a complete MCU (you usually split your application across multiple nodes). Plus it has that very efficient 5-bit instruction encoding. On the other hand, you have to use ram as program memory. You might be able to concoct some usable Forth dialect compiled with an optimizing compiler and using 8-bit data when possible, but it doesn't seem that useful for a chip like this.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2018-10-13 18:31 +0300 |
| Message-ID | <g2eheeF58hmU1@mid.individual.net> |
| In reply to | #28189 |
On 18-10-12 19:11 , gnuarm.deletethisbit@gmail.com wrote:
> On Friday, October 12, 2018 at 2:50:53 AM UTC-4, Philipp Klaus Krause wrote:
>> Am 12.10.2018 um 01:08 schrieb Paul Rubin:
>>> upsidedown@downunder.com writes:
>>>> There is a lot of operations that will update memory locations, so why
>>>> would you need a lot of CPU registers.
>>>
>>> Being able to (say) add register to register saves traffic through the
>>> accumulator and therefore instructions.
>>>
>>>> 1 KiB = 0.5 KiW is quite a lot, it is about 10-15 pages of commented
>>>> assembly program listing.
The data-sheet describes the OTP program memory as "1KW", probably
meaning 1024 instructions. The length of an instruction is not defined,
as far as I could see.
>>> It would be nice to have a C compiler, and registers help with that.
The data-sheet mentions something they call "Mini-C".
>> Looking at the instruction set, it should be possible to make a backend
>> for this in SDCC; the architecture looks more C-friendly than the
>> existing pic14 and pic16 backends. But it surely isn't as nice as stm8
>> or z80.
>> reentrant functions will be inefficent: No registers, and no sp-relative
>> adressing mode. On would want to reserve a few memory locations as
>> pseudo-registers to help with that, but that only goes so far.
>
> CPUs like this (and others that aren't like this) should be programmed
> in Forth.
I don't think that an interpreted Forth is feasible for this particular
MCU. Where would the Forth program (= list of pointers to "words") be
stored? I found no instructions for reading data from the OTP program
memory, and the 64-byte RAM will not hold a non-trivial program together
with the data for that program.
Moreover, there is no indirect jump instruction -- "jump to a computed
address". The closest is "pcadd a", which can be used to implement a
256-entry case statement. You would be limited to a total of 256 words.
Moreover, each RAM-resident pointer to RAM uses 2 octets of RAM, giving
a 16-bit RAM address, although for this MCU a 6-bit address would be
enough. Apparently the same architecture has implementations with more
RAM and 16-bit RAM addresses.
That said, one could perhaps implement a compiled Forth for this machine.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web