Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.arch.embedded Subject: Re: $0.03 microcontroller Date: Sat, 13 Oct 2018 18:31:25 +0300 Organization: Tidorum Ltd Lines: 54 Message-ID: References: <874ldtp66e.fsf@nightsong.com> <87in28nktr.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 0V9zACWIsSFrXm95OVVhag2uEzUqt9ZuCegfQlRXGVmJVet2ba Cancel-Lock: sha1:8S1sKsoI8bsVAAQfc9pjqTgRkzA= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: csiph.com comp.arch.embedded:28198 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 . @ .