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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2018-10-13 19:46 +0300 |
| Message-ID | <g2elr6F63bpU1@mid.individual.net> |
| In reply to | #28198 |
On 18-10-13 18:31 , Niklas Holsti wrote:
> I don't think that an interpreted Forth is feasible for this particular
> MCU. ...
> Moreover, there is no indirect jump instruction -- "jump to a computed
> address".
Ok, before anyone else notices, I admit I forgot about implementing an
indirect jump by pushing the target address on the stack and executing a
return instruction. That would work for this machine.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2018-10-13 19:59 +0300 |
| Message-ID | <g2emirF68vqU1@mid.individual.net> |
| In reply to | #28201 |
And one more iteration (sorry...)
On 18-10-13 19:46 , Niklas Holsti wrote:
> On 18-10-13 18:31 , Niklas Holsti wrote:
>
>> I don't think that an interpreted Forth is feasible for this particular
>> MCU. ...
>> Moreover, there is no indirect jump instruction -- "jump to a computed
>> address".
>
> Ok, before anyone else notices, I admit I forgot about implementing an
> indirect jump by pushing the target address on the stack and executing a
> return instruction. That would work for this machine.
Except that one can only "push" the accumulator and flag registers,
combined, and the flag register cannot be set directly, and has only 4
working bits.
What would work, as an indirect jump, is to set the Stack Pointer (sp)
to point at a RAM word that contains the target address, and then
execute a return. But then one has lost the actual Stack Pointer value.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-13 21:31 +0300 |
| Message-ID | <j4e4sd1njoang9su3d81i9f1rvo5go292b@4ax.com> |
| In reply to | #28202 |
On Sat, 13 Oct 2018 19:59:06 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >And one more iteration (sorry...) > >On 18-10-13 19:46 , Niklas Holsti wrote: >> On 18-10-13 18:31 , Niklas Holsti wrote: >> >>> I don't think that an interpreted Forth is feasible for this particular >>> MCU. ... >>> Moreover, there is no indirect jump instruction -- "jump to a computed >>> address". >> >> Ok, before anyone else notices, I admit I forgot about implementing an >> indirect jump by pushing the target address on the stack and executing a >> return instruction. That would work for this machine. > >Except that one can only "push" the accumulator and flag registers, >combined, and the flag register cannot be set directly, and has only 4 >working bits. > >What would work, as an indirect jump, is to set the Stack Pointer (sp) >to point at a RAM word that contains the target address, and then >execute a return. But then one has lost the actual Stack Pointer value. Just call a "Jumper" routine, the call pushes the return address on stack. In "Jumper" read SP from IO address space, indirectly modify the return address on stack as needed and perform a ret instruction, causing a jump to the modified return address and it also restores the SP to the value before the call.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2018-10-13 22:19 +0300 |
| Message-ID | <g2euqvF7u6rU1@mid.individual.net> |
| In reply to | #28206 |
On 18-10-13 21:31 , upsidedown@downunder.com wrote:
> On Sat, 13 Oct 2018 19:59:06 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> wrote:
>
>> And one more iteration (sorry...)
>>
>> On 18-10-13 19:46 , Niklas Holsti wrote:
>>> On 18-10-13 18:31 , Niklas Holsti wrote:
>>>
>>>> I don't think that an interpreted Forth is feasible for this particular
>>>> MCU. ...
>>>> Moreover, there is no indirect jump instruction -- "jump to a computed
>>>> address".
>>>
>>> Ok, before anyone else notices, I admit I forgot about implementing an
>>> indirect jump by pushing the target address on the stack and executing a
>>> return instruction. That would work for this machine.
>>
>> Except that one can only "push" the accumulator and flag registers,
>> combined, and the flag register cannot be set directly, and has only 4
>> working bits.
>>
>> What would work, as an indirect jump, is to set the Stack Pointer (sp)
>> to point at a RAM word that contains the target address, and then
>> execute a return. But then one has lost the actual Stack Pointer value.
>
> Just call a "Jumper" routine, the call pushes the return address on
> stack. In "Jumper" read SP from IO address space, indirectly modify
> the return address on stack as needed and perform a ret instruction,
> causing a jump to the modified return address and it also restores the
> SP to the value before the call.
Right, that sounds possible. But wow what a circumlocution.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-13 21:24 +0200 |
| Message-ID | <pptgpb$huc$1@solani.org> |
| In reply to | #28202 |
Am 13.10.2018 um 18:59 schrieb Niklas Holsti: > > Except that one can only "push" the accumulator and flag registers, > combined, and the flag register cannot be set directly, and has only 4 > working bits. It seems unclear to me which of acc and sp is pushed first. But if acc is pushed first, one could do pushaf; mov a, sp; inc a; mov sp, a; to push any desired byte onto the stack. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2018-10-13 22:50 +0300 |
| Message-ID | <g2f0l1F8agkU1@mid.individual.net> |
| In reply to | #28208 |
On 18-10-13 22:24 , Philipp Klaus Krause wrote:
> Am 13.10.2018 um 18:59 schrieb Niklas Holsti:
>>
>> Except that one can only "push" the accumulator and flag registers,
>> combined, and the flag register cannot be set directly, and has only 4
>> working bits.
>
> It seems unclear to me which of acc and sp is pushed first.
> But if acc is pushed first, one could do
>
> pushaf;
> mov a, sp;
> inc a;
> mov sp, a;
>
> to push any desired byte onto the stack.
There's also a rule that the sp must always contain an even address, at
least if interrupts are enabled, as I understand it.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-14 14:39 +0200 |
| Message-ID | <ppvddb$ro$2@dont-email.me> |
| In reply to | #28202 |
On 13/10/18 18:59, Niklas Holsti wrote: > And one more iteration (sorry...) > > On 18-10-13 19:46 , Niklas Holsti wrote: >> On 18-10-13 18:31 , Niklas Holsti wrote: >> >>> I don't think that an interpreted Forth is feasible for this particular >>> MCU. ... >>> Moreover, there is no indirect jump instruction -- "jump to a computed >>> address". >> >> Ok, before anyone else notices, I admit I forgot about implementing an >> indirect jump by pushing the target address on the stack and executing a >> return instruction. That would work for this machine. > > Except that one can only "push" the accumulator and flag registers, > combined, and the flag register cannot be set directly, and has only 4 > working bits. > > What would work, as an indirect jump, is to set the Stack Pointer (sp) > to point at a RAM word that contains the target address, and then > execute a return. But then one has lost the actual Stack Pointer value. > Or you could read the SP, put that address into a different word memory location, and use that for indirect access to write to the stack. It is all possible, but not particularly efficient.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-15 05:11 -0700 |
| Message-ID | <9ec378f5-c10c-4b82-b5c7-f61be390a3e9@googlegroups.com> |
| In reply to | #28225 |
On Sunday, October 14, 2018 at 8:39:10 AM UTC-4, David Brown wrote: > On 13/10/18 18:59, Niklas Holsti wrote: > > And one more iteration (sorry...) > > > > On 18-10-13 19:46 , Niklas Holsti wrote: > >> On 18-10-13 18:31 , Niklas Holsti wrote: > >> > >>> I don't think that an interpreted Forth is feasible for this particular > >>> MCU. ... > >>> Moreover, there is no indirect jump instruction -- "jump to a computed > >>> address". > >> > >> Ok, before anyone else notices, I admit I forgot about implementing an > >> indirect jump by pushing the target address on the stack and executing a > >> return instruction. That would work for this machine. > > > > Except that one can only "push" the accumulator and flag registers, > > combined, and the flag register cannot be set directly, and has only 4 > > working bits. > > > > What would work, as an indirect jump, is to set the Stack Pointer (sp) > > to point at a RAM word that contains the target address, and then > > execute a return. But then one has lost the actual Stack Pointer value. > > > > Or you could read the SP, put that address into a different word memory > location, and use that for indirect access to write to the stack. > > It is all possible, but not particularly efficient. Efficiency has to be relative on such a limited machine. If there are no registers nearly everything is going to be clumsy and slow. I'm not sure using this CPU with Forth would be at all bad even if the CPU is not intended for Forth. One of the things that makes Forth so useful is that it can be tailored to the target. Rather than use the standard words you can write your own words that better fit the architecture. I'm not a Forth system designer, but I have designed CPUs in FPGAs and being able to target my CPU design with Forth is great. My CPU uses an 8 or 9 bit instruction size with multibyte instructions by prepending immediate addresses or data. I was able to make that work easily in Forth while it would have been a bear in C or other languages. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-13 21:03 +0300 |
| Message-ID | <kic4sdhioa4vr6en2qr03kqllrbkeug0np@4ax.com> |
| In reply to | #28198 |
On Sat, 13 Oct 2018 18:31:25 +0300, Niklas Holsti <niklas.holsti@tidorum.invalid> wrote: >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. Yes, I misread the data sheet. It is really 1 kW. The nice feature about Harvard architecture is that the data and instruction size can be different. I have tried to locate the bit allocation of various fields (opcode, address etc.) ut no luck.
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-13 18:25 -0700 |
| Message-ID | <8fe895c8-4c05-4b01-8315-5d76dd182a92@googlegroups.com> |
| In reply to | #28198 |
On Saturday, October 13, 2018 at 11:31:30 AM UTC-4, Niklas Holsti wrote: > 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. For programs on such a small MCU 256 words is likely much overkill. But you don't need to have the above features for Forth. Subroutine threading uses call and return instructions instead of an address list. > 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. Yeah, I'm pretty sure it is too small for a resident Forth, so a host would be required and a Forth can be compiled and subroutine threaded. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-10-15 14:20 +0200 |
| Message-ID | <pq20m7$hmp$2@solani.org> |
| In reply to | #28186 |
Am 12.10.2018 um 08:50 schrieb Philipp Klaus Krause: > On would want to reserve a few memory locations as > pseudo-registers to help with that, but that only goes so far. On the other hand, saving those pseudo-registers at interrupts and across function calls will be painful. Philipp
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2018-10-21 16:27 +0300 |
| Message-ID | <k2tosdpcrt38bsc6mlbnet14hd8jnb3kkn@4ax.com> |
| In reply to | #28180 |
On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >Clifford Heath <no.spam@please.net> writes: >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >> OTP, no SPI, UART or I²C, but still... > >That is impressive! Seems to be an 8-bit RISC with no registers, just >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. >I like that it's in a 6-pin SOT23 package since there aren't many other >MCUs that small. Slightly OT, but I have often wonder how primitive a computer architecture can be and still do some useful work. In the tube/discrete/SSI times, there were quite a lot 1 bit processors. There were at least two types, the PLC (programmable Logic Controller) type replacing relay logic. These had typically at least AND, OR, NOT, (XOR) instructions.The other group was used as truly serial computers with the same instructions as the PLC but also at least a 1 bit SUB (and ADD) instructions to implement all mathematical functions. However, in the LSI era, there down't seem to be many implement ions. One that immediately comes in mind is the MC14500B PLC building block, from the 1970's, which requires quite lot of support chips (code memory, PC, /O chips) to do some useful work. After much searching, I found the (NI) National Instruments SBA (Serial Boolean Analyser) http://www.wass.net/othermanuals/GI%20SBA.pdf from the same era, with 1024 word instructions (8 bit) ROM and four banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. For the re-entrance enthusiasts, it contains stack pointer relative addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 Darlington buffers may be needed to drive loads typically found in PLC environment. Anyone seen more modern 1 bit chips either for relay replacement or for truly serial computers ?
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2018-10-21 07:47 -0700 |
| Message-ID | <12e76636-e54a-46cf-bc83-885ffb61c2d4@googlegroups.com> |
| In reply to | #28264 |
On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > <no.email@nospam.invalid> wrote: > > >Clifford Heath <no.spam@please.net> writes: > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > >> OTP, no SPI, UART or I涎, but still... > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > >I like that it's in a 6-pin SOT23 package since there aren't many other > >MCUs that small. > > Slightly OT, but I have often wonder how primitive a computer > architecture can be and still do some useful work. In the > tube/discrete/SSI times, there were quite a lot 1 bit processors. > There were at least two types, the PLC (programmable Logic Controller) > type replacing relay logic. These had typically at least AND, OR, NOT, > (XOR) instructions.The other group was used as truly serial computers > with the same instructions as the PLC but also at least a 1 bit SUB > (and ADD) instructions to implement all mathematical functions. > > However, in the LSI era, there down't seem to be many implement ions. > > One that immediately comes in mind is the MC14500B PLC building block, > from the 1970's, which requires quite lot of support chips (code > memory, PC, /O chips) to do some useful work. > > After much searching, I found the (NI) National Instruments SBA > (Serial Boolean Analyser) > http://www.wass.net/othermanuals/GI%20SBA.pdf > from the same era, with 1024 word instructions (8 bit) ROM and four > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > For the re-entrance enthusiasts, it contains stack pointer relative > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > Darlington buffers may be needed to drive loads typically found in PLC > environment. > > Anyone seen more modern 1 bit chips either for relay replacement or > for truly serial computers ? ]> Anyone seen more modern 1 bit chips either for relay replacement or ]> for truly serial computers ? LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose (Logic Emulation Machine) https://opencores.org/project/lem1_9min Jim Brakefield
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-21 08:08 -0700 |
| Message-ID | <27e6a7c3-f8df-46a1-a410-1f6909e26e42@googlegroups.com> |
| In reply to | #28265 |
On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote: > On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: > > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > > <no.email@nospam.invalid> wrote: > > > > >Clifford Heath <no.spam@please.net> writes: > > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > >> OTP, no SPI, UART or I涎, but still... > > > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > > >I like that it's in a 6-pin SOT23 package since there aren't many other > > >MCUs that small. > > > > Slightly OT, but I have often wonder how primitive a computer > > architecture can be and still do some useful work. In the > > tube/discrete/SSI times, there were quite a lot 1 bit processors. > > There were at least two types, the PLC (programmable Logic Controller) > > type replacing relay logic. These had typically at least AND, OR, NOT, > > (XOR) instructions.The other group was used as truly serial computers > > with the same instructions as the PLC but also at least a 1 bit SUB > > (and ADD) instructions to implement all mathematical functions. > > > > However, in the LSI era, there down't seem to be many implement ions. > > > > One that immediately comes in mind is the MC14500B PLC building block, > > from the 1970's, which requires quite lot of support chips (code > > memory, PC, /O chips) to do some useful work. > > > > After much searching, I found the (NI) National Instruments SBA > > (Serial Boolean Analyser) > > http://www.wass.net/othermanuals/GI%20SBA.pdf > > from the same era, with 1024 word instructions (8 bit) ROM and four > > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > > For the re-entrance enthusiasts, it contains stack pointer relative > > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > > Darlington buffers may be needed to drive loads typically found in PLC > > environment. > > > > Anyone seen more modern 1 bit chips either for relay replacement or > > for truly serial computers ? > > ]> Anyone seen more modern 1 bit chips either for relay replacement or > ]> for truly serial computers ? > > LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose > (Logic Emulation Machine) https://opencores.org/project/lem1_9min > > Jim Brakefield It is hard for me to imagine applications where a 1 bit processor would be useful. A useful N bit processor can be built in a small number of LUTs. I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. I discussed this with someone once and he imagined apps where the processing speed requirement was quite low and you can save LUTs with a bit serial processor. I just don't know how many or why it would matter. Even the smallest FPGAs have thousands of LUTs. It's hard to picture an application where you couldn't spare a few hundred LUTs. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2018-10-21 09:31 -0700 |
| Message-ID | <08bff1a8-c3eb-48b5-a29a-046bb03c3f6b@googlegroups.com> |
| In reply to | #28267 |
On Sunday, October 21, 2018 at 10:08:06 AM UTC-5, gnuarm.del...@gmail.com wrote: > On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote: > > On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: > > > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > > > <no.email@nospam.invalid> wrote: > > > > > > >Clifford Heath <no.spam@please.net> writes: > > > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > > > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > > >> OTP, no SPI, UART or I涎, but still... > > > > > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > > > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > > > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > > > >I like that it's in a 6-pin SOT23 package since there aren't many other > > > >MCUs that small. > > > > > > Slightly OT, but I have often wonder how primitive a computer > > > architecture can be and still do some useful work. In the > > > tube/discrete/SSI times, there were quite a lot 1 bit processors. > > > There were at least two types, the PLC (programmable Logic Controller) > > > type replacing relay logic. These had typically at least AND, OR, NOT, > > > (XOR) instructions.The other group was used as truly serial computers > > > with the same instructions as the PLC but also at least a 1 bit SUB > > > (and ADD) instructions to implement all mathematical functions. > > > > > > However, in the LSI era, there down't seem to be many implement ions. > > > > > > One that immediately comes in mind is the MC14500B PLC building block, > > > from the 1970's, which requires quite lot of support chips (code > > > memory, PC, /O chips) to do some useful work. > > > > > > After much searching, I found the (NI) National Instruments SBA > > > (Serial Boolean Analyser) > > > http://www.wass.net/othermanuals/GI%20SBA.pdf > > > from the same era, with 1024 word instructions (8 bit) ROM and four > > > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > > > For the re-entrance enthusiasts, it contains stack pointer relative > > > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > > > Darlington buffers may be needed to drive loads typically found in PLC > > > environment. > > > > > > Anyone seen more modern 1 bit chips either for relay replacement or > > > for truly serial computers ? > > > > ]> Anyone seen more modern 1 bit chips either for relay replacement or > > ]> for truly serial computers ? > > > > LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose > > (Logic Emulation Machine) https://opencores.org/project/lem1_9min > > > > Jim Brakefield > > It is hard for me to imagine applications where a 1 bit processor would be useful. A useful N bit processor can be built in a small number of LUTs. I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. > > I discussed this with someone once and he imagined apps where the processing speed requirement was quite low and you can save LUTs with a bit serial processor. I just don't know how many or why it would matter. Even the smallest FPGAs have thousands of LUTs. It's hard to picture an application where you couldn't spare a few hundred LUTs. > > Rick C. ]>It's hard to picture an application where you couldn't spare a few hundred LUTs. There are advantages to using several soft core processors, each sized and customized to the need. ]>I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. There are many under 600 LUTs, including 32-bit. Had hoped the full featured LEM design would be under 100 LUTs. Have done some rough research of whats available for under 600 LUTs: https://opencores.org/project/up_core_list/downloads select: "By Performance Metric" A big rational for small soft core processors is that they replace LUTs (slow speed logic) with block RAM (instructions). And they are completely deterministic as opposed to doing the same by time slicing a ASIC (ARM) processor. Jim Brakefield
[toc] | [prev] | [next] | [standalone]
| From | gnuarm.deletethisbit@gmail.com |
|---|---|
| Date | 2018-10-21 10:51 -0700 |
| Message-ID | <0c812dc7-ef37-4428-ab2d-20d246d1fddd@googlegroups.com> |
| In reply to | #28268 |
On Sunday, October 21, 2018 at 12:31:34 PM UTC-4, jim.bra...@ieee.org wrote: > On Sunday, October 21, 2018 at 10:08:06 AM UTC-5, gnuarm.del...@gmail.com wrote: > > On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote: > > > On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: > > > > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > > > > <no.email@nospam.invalid> wrote: > > > > > > > > >Clifford Heath <no.spam@please.net> writes: > > > > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > > > > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > > > >> OTP, no SPI, UART or I涎, but still... > > > > > > > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > > > > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > > > > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > > > > >I like that it's in a 6-pin SOT23 package since there aren't many other > > > > >MCUs that small. > > > > > > > > Slightly OT, but I have often wonder how primitive a computer > > > > architecture can be and still do some useful work. In the > > > > tube/discrete/SSI times, there were quite a lot 1 bit processors. > > > > There were at least two types, the PLC (programmable Logic Controller) > > > > type replacing relay logic. These had typically at least AND, OR, NOT, > > > > (XOR) instructions.The other group was used as truly serial computers > > > > with the same instructions as the PLC but also at least a 1 bit SUB > > > > (and ADD) instructions to implement all mathematical functions. > > > > > > > > However, in the LSI era, there down't seem to be many implement ions. > > > > > > > > One that immediately comes in mind is the MC14500B PLC building block, > > > > from the 1970's, which requires quite lot of support chips (code > > > > memory, PC, /O chips) to do some useful work. > > > > > > > > After much searching, I found the (NI) National Instruments SBA > > > > (Serial Boolean Analyser) > > > > http://www.wass.net/othermanuals/GI%20SBA.pdf > > > > from the same era, with 1024 word instructions (8 bit) ROM and four > > > > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > > > > For the re-entrance enthusiasts, it contains stack pointer relative > > > > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > > > > Darlington buffers may be needed to drive loads typically found in PLC > > > > environment. > > > > > > > > Anyone seen more modern 1 bit chips either for relay replacement or > > > > for truly serial computers ? > > > > > > ]> Anyone seen more modern 1 bit chips either for relay replacement or > > > ]> for truly serial computers ? > > > > > > LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose > > > (Logic Emulation Machine) https://opencores.org/project/lem1_9min > > > > > > Jim Brakefield > > > > It is hard for me to imagine applications where a 1 bit processor would be useful. A useful N bit processor can be built in a small number of LUTs. I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. > > > > I discussed this with someone once and he imagined apps where the processing speed requirement was quite low and you can save LUTs with a bit serial processor. I just don't know how many or why it would matter. Even the smallest FPGAs have thousands of LUTs. It's hard to picture an application where you couldn't spare a few hundred LUTs. > > > > Rick C. > > ]>It's hard to picture an application where you couldn't spare a few hundred LUTs. > > There are advantages to using several soft core processors, each sized and customized to the need. > > ]>I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. > > There are many under 600 LUTs, including 32-bit. Had hoped the full featured LEM design would be under 100 LUTs. > Have done some rough research of whats available for under 600 LUTs: https://opencores.org/project/up_core_list/downloads > select: "By Performance Metric" > > A big rational for small soft core processors is that they replace LUTs (slow speed logic) with block RAM (instructions). And they are completely deterministic as opposed to doing the same by time slicing a ASIC (ARM) processor. I won't argue a bit that softcores and especially *customizable* softcore CPUs aren't useful. I was talking about there being at best a very tiny region of utility for 1-bit processors. My 600 LUT processor didn't trade off much for performance. It would run pretty fast and was pretty capable. In addition the word size was independent of the instruction set. That said, there are apps where a much less powerful processor would do fine and saving a few more LUTs would be useful. Rick C.
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2018-10-21 12:44 -0700 |
| Message-ID | <b946531a-5315-4e18-b4ff-9445bc6308e2@googlegroups.com> |
| In reply to | #28269 |
On Sunday, October 21, 2018 at 12:51:34 PM UTC-5, gnuarm.del...@gmail.com wrote: > On Sunday, October 21, 2018 at 12:31:34 PM UTC-4, jim.bra...@ieee.org wrote: > > On Sunday, October 21, 2018 at 10:08:06 AM UTC-5, gnuarm.del...@gmail.com wrote: > > > On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote: > > > > On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: > > > > > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > > > > > <no.email@nospam.invalid> wrote: > > > > > > > > > > >Clifford Heath <no.spam@please.net> writes: > > > > > >> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> > > > > > >> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> > > > > > >> OTP, no SPI, UART or I涎, but still... > > > > > > > > > > > >That is impressive! Seems to be an 8-bit RISC with no registers, just > > > > > >an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, > > > > > >enough for plenty of MCU things. Didn't check if it has an ADC or PWM. > > > > > >I like that it's in a 6-pin SOT23 package since there aren't many other > > > > > >MCUs that small. > > > > > > > > > > Slightly OT, but I have often wonder how primitive a computer > > > > > architecture can be and still do some useful work. In the > > > > > tube/discrete/SSI times, there were quite a lot 1 bit processors. > > > > > There were at least two types, the PLC (programmable Logic Controller) > > > > > type replacing relay logic. These had typically at least AND, OR, NOT, > > > > > (XOR) instructions.The other group was used as truly serial computers > > > > > with the same instructions as the PLC but also at least a 1 bit SUB > > > > > (and ADD) instructions to implement all mathematical functions. > > > > > > > > > > However, in the LSI era, there down't seem to be many implement ions. > > > > > > > > > > One that immediately comes in mind is the MC14500B PLC building block, > > > > > from the 1970's, which requires quite lot of support chips (code > > > > > memory, PC, /O chips) to do some useful work. > > > > > > > > > > After much searching, I found the (NI) National Instruments SBA > > > > > (Serial Boolean Analyser) > > > > > http://www.wass.net/othermanuals/GI%20SBA.pdf > > > > > from the same era, with 1024 word instructions (8 bit) ROM and four > > > > > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > > > > > For the re-entrance enthusiasts, it contains stack pointer relative > > > > > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > > > > > Darlington buffers may be needed to drive loads typically found in PLC > > > > > environment. > > > > > > > > > > Anyone seen more modern 1 bit chips either for relay replacement or > > > > > for truly serial computers ? > > > > > > > > ]> Anyone seen more modern 1 bit chips either for relay replacement or > > > > ]> for truly serial computers ? > > > > > > > > LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose > > > > (Logic Emulation Machine) https://opencores.org/project/lem1_9min > > > > > > > > Jim Brakefield > > > > > > It is hard for me to imagine applications where a 1 bit processor would be useful. A useful N bit processor can be built in a small number of LUTs. I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. > > > > > > I discussed this with someone once and he imagined apps where the processing speed requirement was quite low and you can save LUTs with a bit serial processor. I just don't know how many or why it would matter. Even the smallest FPGAs have thousands of LUTs. It's hard to picture an application where you couldn't spare a few hundred LUTs. > > > > > > Rick C. > > > > ]>It's hard to picture an application where you couldn't spare a few hundred LUTs. > > > > There are advantages to using several soft core processors, each sized and customized to the need. > > > > ]>I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. > > > > There are many under 600 LUTs, including 32-bit. Had hoped the full featured LEM design would be under 100 LUTs. > > Have done some rough research of whats available for under 600 LUTs: https://opencores.org/project/up_core_list/downloads > > select: "By Performance Metric" > > > > A big rational for small soft core processors is that they replace LUTs (slow speed logic) with block RAM (instructions). And they are completely deterministic as opposed to doing the same by time slicing a ASIC (ARM) processor. > > I won't argue a bit that softcores and especially *customizable* softcore CPUs aren't useful. I was talking about there being at best a very tiny region of utility for 1-bit processors. > > My 600 LUT processor didn't trade off much for performance. It would run pretty fast and was pretty capable. In addition the word size was independent of the instruction set. That said, there are apps where a much less powerful processor would do fine and saving a few more LUTs would be useful. > > Rick C. ]>there being at best a very tiny region of utility for 1-bit processors There are a small number of examples: Bit serial processors such as DEC PDP8L, early vacuum tube & drum machines, for example Bendix G-15. Bit serial Cordic Also telling, is that 4-bit processors for calculators have been replaced by 8-bit processors. My inspiration was EDIF, which was/is output from VHDL & Verilog compilers. E.g. use EDIF as a machine language. In the context of logic simulation, greater FPGA capacity possible for slow logic. This effort also lead to a theoretical insight for brain modelling: There is greater information content in the wiring than in the logic. The human brain has 2<<36+ neurons requiring 36-bits of information for each connection and only 16 or so bits for the state/configuration of each synapse. Also a FPGA requires 60+ bits to route each LUT input (assuming all LUT inputs in use) whereas each possible input can be specified by 20 bits or less (1M LUT FPGA). Of course optimizing simulators convert the EDIF to an existing machine language. Likewise for industrial automation (ladder logic, ...). Jim Brakefield
[toc] | [prev] | [next] | [standalone]
| From | Brett <ggtgp@yahoo.com> |
|---|---|
| Date | 2018-10-22 00:28 +0000 |
| Message-ID | <pqj5k3$8ga$1@dont-email.me> |
| In reply to | #28271 |
<jim.brakefield@ieee.org> wrote: > On Sunday, October 21, 2018 at 12:51:34 PM UTC-5, gnuarm.del...@gmail.com wrote: >> On Sunday, October 21, 2018 at 12:31:34 PM UTC-4, jim.bra...@ieee.org wrote: >>> On Sunday, October 21, 2018 at 10:08:06 AM UTC-5, gnuarm.del...@gmail.com wrote: >>>> On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote: >>>>> On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.com wrote: >>>>>> On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin >>>>>> <no.email@nospam.invalid> wrote: >>>>>> >>>>>>> Clifford Heath <no.spam@please.net> writes: >>>>>>>> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >>>>>>>> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >>>>>>>> OTP, no SPI, UART or I涎, but still... >>>>>>> >>>>>>> That is impressive! Seems to be an 8-bit RISC with no registers, just >>>>>>> an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, >>>>>>> enough for plenty of MCU things. Didn't check if it has an ADC or PWM. >>>>>>> I like that it's in a 6-pin SOT23 package since there aren't many other >>>>>>> MCUs that small. >>>>>> >>>>>> Slightly OT, but I have often wonder how primitive a computer >>>>>> architecture can be and still do some useful work. In the >>>>>> tube/discrete/SSI times, there were quite a lot 1 bit processors. >>>>>> There were at least two types, the PLC (programmable Logic Controller) >>>>>> type replacing relay logic. These had typically at least AND, OR, NOT, >>>>>> (XOR) instructions.The other group was used as truly serial computers >>>>>> with the same instructions as the PLC but also at least a 1 bit SUB >>>>>> (and ADD) instructions to implement all mathematical functions. >>>>>> >>>>>> However, in the LSI era, there down't seem to be many implement ions. >>>>>> >>>>>> One that immediately comes in mind is the MC14500B PLC building block, >>>>>> from the 1970's, which requires quite lot of support chips (code >>>>>> memory, PC, /O chips) to do some useful work. >>>>>> >>>>>> After much searching, I found the (NI) National Instruments SBA >>>>>> (Serial Boolean Analyser) >>>>>> http://www.wass.net/othermanuals/GI%20SBA.pdf >>>>>> from the same era, with 1024 word instructions (8 bit) ROM and four >>>>>> banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. >>>>>> For the re-entrance enthusiasts, it contains stack pointer relative >>>>>> addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 >>>>>> Darlington buffers may be needed to drive loads typically found in PLC >>>>>> environment. >>>>>> >>>>>> Anyone seen more modern 1 bit chips either for relay replacement or >>>>>> for truly serial computers ? >>>>> >>>>> ]> Anyone seen more modern 1 bit chips either for relay replacement or >>>>> ]> for truly serial computers ? >>>>> >>>>> LEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose >>>>> (Logic Emulation Machine) https://opencores.org/project/lem1_9min >>>>> >>>>> Jim Brakefield >>>> >>>> It is hard for me to imagine applications where a 1 bit processor >>>> would be useful. A useful N bit processor can be built in a small >>>> number of LUTs. I've built a 16 bit processor in just 600 LUTs and >>>> I've seen processors in a bit less. >>>> >>>> I discussed this with someone once and he imagined apps where the >>>> processing speed requirement was quite low and you can save LUTs with >>>> a bit serial processor. I just don't know how many or why it would >>>> matter. Even the smallest FPGAs have thousands of LUTs. It's hard to >>>> picture an application where you couldn't spare a few hundred LUTs. >>>> >>>> Rick C. >>> >>> ]>It's hard to picture an application where you couldn't spare a few hundred LUTs. >>> >>> There are advantages to using several soft core processors, each sized >>> and customized to the need. >>> >>> ]>I've built a 16 bit processor in just 600 LUTs and I've seen processors in a bit less. >>> >>> There are many under 600 LUTs, including 32-bit. Had hoped the full >>> featured LEM design would be under 100 LUTs. >>> Have done some rough research of whats available for under 600 LUTs: >>> https://opencores.org/project/up_core_list/downloads >>> select: "By Performance Metric" >>> >>> A big rational for small soft core processors is that they replace LUTs >>> (slow speed logic) with block RAM (instructions). And they are >>> completely deterministic as opposed to doing the same by time slicing a >>> ASIC (ARM) processor. >> >> I won't argue a bit that softcores and especially *customizable* >> softcore CPUs aren't useful. I was talking about there being at best a >> very tiny region of utility for 1-bit processors. >> >> My 600 LUT processor didn't trade off much for performance. It would >> run pretty fast and was pretty capable. In addition the word size was >> independent of the instruction set. That said, there are apps where a >> much less powerful processor would do fine and saving a few more LUTs would be useful. >> >> Rick C. > > ]>there being at best a very tiny region of utility for 1-bit processors > > There are a small number of examples: > Bit serial processors such as DEC PDP8L, early vacuum tube & drum > machines, for example Bendix G-15. > Bit serial Cordic > > Also telling, is that 4-bit processors for calculators have been replaced > by 8-bit processors. > > My inspiration was EDIF, which was/is output from VHDL & Verilog > compilers. E.g. use EDIF as a machine language. In the context of logic > simulation, greater FPGA capacity possible for slow logic. > > This effort also lead to a theoretical insight for brain modelling: There > is greater information content in the wiring than in the logic. The > human brain has 2<<36+ neurons requiring 36-bits of information for each > connection and only 16 or so bits for the state/configuration of each > synapse. Also a FPGA requires 60+ bits to route each LUT input (assuming > all LUT inputs in use) whereas each possible input can be specified by 20 > bits or less (1M LUT FPGA). The clock speed is quite low, 2 Hz? So the wetware is is not quite impossible to emulate with current tech. Raising a baby and training the resultant adult to do a task is still many orders of magnitude cheaper. ;) > Of course optimizing simulators convert the EDIF to an existing machine > language. Likewise for industrial automation (ladder logic, ...). > > Jim Brakefield >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-21 21:43 +0200 |
| Message-ID | <pqiktg$b83$1@dont-email.me> |
| In reply to | #28267 |
On 21/10/2018 17:08, gnuarm.deletethisbit@gmail.com wrote: > > It is hard for me to imagine applications where a 1 bit processor > would be useful. A useful N bit processor can be built in a small > number of LUTs. I've built a 16 bit processor in just 600 LUTs and > I've seen processors in a bit less. > > I discussed this with someone once and he imagined apps where the > processing speed requirement was quite low and you can save LUTs with > a bit serial processor. I just don't know how many or why it would > matter. Even the smallest FPGAs have thousands of LUTs. It's hard > to picture an application where you couldn't spare a few hundred > LUTs. > There is not much point in 1-bit processing with modern architectures and FPGAs. But it used to be more useful, for cheap and scalable solutions. You got systems that scaled in parallel, using bit-slice processors to make cpus as wide as you want. And you got serial scaling, giving you practical numbers of bits with minimal die area (like the COP8 microcontrollers).
[toc] | [prev] | [next] | [standalone]
| From | Phil Martel <pomartel@comcast.net> |
|---|---|
| Date | 2018-10-21 11:03 -0400 |
| Message-ID | <Wy0zD.156626$X82.119373@fx22.iad> |
| In reply to | #28264 |
On 10/21/2018 09:27, upsidedown@downunder.com wrote: > On Wed, 10 Oct 2018 19:29:13 -0700, Paul Rubin > <no.email@nospam.invalid> wrote: > >> Clifford Heath <no.spam@please.net> writes: >>> <https://lcsc.com/product-detail/PADAUK_PADAUK-Tech-PMS150C_C129127.html> >>> <http://www.padauk.com.tw/upload/doc/PMS150C%20datasheet%20V004_EN_20180124.pdf> >>> OTP, no SPI, UART or I²C, but still... >> >> That is impressive! Seems to be an 8-bit RISC with no registers, just >> an accumulator, a cute concept. 1K of program OTP and 64 bytes of ram, >> enough for plenty of MCU things. Didn't check if it has an ADC or PWM. >> I like that it's in a 6-pin SOT23 package since there aren't many other >> MCUs that small. > > Slightly OT, but I have often wonder how primitive a computer > architecture can be and still do some useful work. In the > tube/discrete/SSI times, there were quite a lot 1 bit processors. > There were at least two types, the PLC (programmable Logic Controller) > type replacing relay logic. These had typically at least AND, OR, NOT, > (XOR) instructions.The other group was used as truly serial computers > with the same instructions as the PLC but also at least a 1 bit SUB > (and ADD) instructions to implement all mathematical functions. > > However, in the LSI era, there down't seem to be many implement ions. > > One that immediately comes in mind is the MC14500B PLC building block, > from the 1970's, which requires quite lot of support chips (code > memory, PC, /O chips) to do some useful work. > > After much searching, I found the (NI) National Instruments SBA > (Serial Boolean Analyser) > http://www.wass.net/othermanuals/GI%20SBA.pdf > from the same era, with 1024 word instructions (8 bit) ROM and four > banks of 30 _bits_ data memory and 30 I/O pins in a 40 pin package. > For the re-entrance enthusiasts, it contains stack pointer relative > addressing :-). THe I/O pins are 5 V TTL compatible, so a few ULN2803 > Darlington buffers may be needed to drive loads typically found in PLC > environment. > > Anyone seen more modern 1 bit chips either for relay replacement or > for truly serial computers ? > I have a memory of a 1-bit GPU from the late 70's, but can't pin it down. There is an article on Wikipedia https://en.wikipedia.org/wiki/1-bit_architecture -- Best wishes, --Phil pomartel At Comcast(ignore_this) dot net
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web