On Wednesday, October 17, 2018 at 11:37:14 AM UTC-4, Niklas Holsti
wrote:
On 18-10-17 17:08 , gnuarm.deletethisbit@gmail.com wrote:
On Wednesday, October 17, 2018 at 2:35:46 AM UTC-4, Niklas
Holsti wrote:
On 18-10-17 01:46 , David Brown wrote: ...
When I am faced with someone else's code to examine or
maintain, I often run it through Doxygen with "generate
documentation for /everything/ - caller graphs, callee
graphs, cross-linked source, etc." It can make it quick to
jump around in the code. And recursive (or re-entrant,
whichever you prefer) code stands out like a sore thumb, as
long as the code is single-threaded - you get loops in the
call graphs.
Anecdote: some years ago, when I was applying a WCET analysis
tool to someone else's program, the tool found recursion. This
surprised the people I was working with, because they had
generated call graphs for the program, analysed them visually,
and found no recursive, looping paths.
Turned out that they had asked the call-graph tool to optimize
the size of the window used to display the call-graphs. The
tool did as it was told, with the result that the line segments
on the path for the recursive call went down to the bottom edge
of the diagram, then *merged* with the lower border line of the
diagram, followed that lower border, went up one side of the
diagram -- still merged with the border line -- and then
reentered the diagram to point at the source of the recursive
call, effectively making the loop very hard to see...
(It turned out that this recursion was intentional. At this
point, the program was sending an alarm message, but the alarm
buffer was full, so the alarm routine called itself to send an
alarm about the full buffer -- and that worked, because one
buffer slot was reserved, by design, for this "buffer full"
alarm.)
Seems to me what actually failed was that they knew they had
recursion in the design but didn't realize the fact that they
didn't see the recursion in the call graphs was an error that
should have been caught.
The guys creating and viewing the call-graphs were not the
designers of the program, either, so they didn't know, but for sure
it was something they should have discovered and remarked on as
part of their work.
Do you know the intended purpose of the call graphs?
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.
On Wed, 10 Oct 2018 19:29:13 -0700, Paul RubinLEM1_9 and LEM4_9 are FPGA soft cores that are intended for that purpose
<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 ?
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 ?
On Sunday, October 21, 2018 at 8:27:35 AM UTC-5, upsid...@downunder.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.
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
On Sunday, October 21, 2018 at 10:47:26 AM UTC-4, jim.bra...@ieee.org wrote:There are advantages to using several soft core processors, each sized and customized to the need.
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.
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.
On Sunday, October 21, 2018 at 10:08:06 AM UTC-5, gnuarm.del...@gmail.com wrote: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.
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.
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.
On Sunday, October 21, 2018 at 12:31:34 PM UTC-4, jim.bra...@ieee.org wrote:There are a small number of examples:
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
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
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 ?
Tim <cpldcpu+usenet@gmail.com> wrote:
This is quite curious. I wonder
- Has anyone actually received the devices they ordered? The cheaper
variants seem to be sold out.
I think they've sold out since they went viral. EEVblog did a video showing 550 in stock - that's only $16 worth of parts, not hard to imagine they've been bought up.
The other option is they're some kind of EOL part and 3c is the 'reduced to clear' price - which they have done, very successfully.
Theo
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.
On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk@spth.de>
wrote:
Am 10.10.2018 um 03:05 schrieb Clifford Heath:
<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...
Clifford Heath
They even make dual-core variants (the part where the first digit in the
part number is '2'). It seems program counter, stack pointer, flag
register and accumulator are per-core, while the rest, including the ALU
is shared. In particular, the I/O registers are also shared, which means
some multiplier registers would also be - but currently all variants
with integrated multiplier are single-core.
Use of the ALU is shared byt he two cores, alternating by clock cycle.
Philipp
Interesting, that would make it easy to run a multitasking RTOS (foreground/background) monitor, which might justify the use of some reentrant library routines :-). But in reality, the available memory (ROM/RAM) is so small so that you could easily manage this with static
memory allocations.
Am 12.10.18 um 20:39 schrieb upsidedown@downunder.com:
On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk@spth.de>
wrote:
Am 10.10.2018 um 03:05 schrieb Clifford Heath:
<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...
Clifford Heath
They even make dual-core variants (the part where the first digit in the >>> part number is '2'). It seems program counter, stack pointer, flag
register and accumulator are per-core, while the rest, including the ALU >>> is shared. In particular, the I/O registers are also shared, which means >>> some multiplier registers would also be - but currently all variants
with integrated multiplier are single-core.
Use of the ALU is shared byt he two cores, alternating by clock cycle.
Philipp
Interesting, that would make it easy to run a multitasking RTOS
(foreground/background) monitor, which might justify the use of some
reentrant library routines :-). But in reality, the available memory
(ROM/RAM) is so small so that you could easily manage this with static
memory allocations.
But static memory allocation would require one copy of each function per thread. And the linker would have to analyze the call graph to always
call the correct function for each thread. Function pointers get
complicated.
Unfortunately, reentrancy becomes even harder with
hardware-multithreading: TO access the stack, one has to construct a
pointer to the stack location in a memory location. That memory location
(as any pseudo-registers) is then shared among all running instances of
the function. So it needs to be protected (e.g. with a spinlock), making access even more inefficient. And that spinlock will cause issues with interrupts (a solution might be to heavily restrict interrupt routines, essentially allowing not much more than setting some global variables).
The there is the trade-off of using one such memory location per
function vs. per program (the latter reducing memroy usage, but
resulting in less paralellism).
The pseudo-registers one would want to use are not so much a problem for interrupt routines (they would just need saving and thus increase
interrupt overhead a bit), but for hardware parallelism. Essentially all access to them would again have to be protected by a spinlock.
All these problems could have relatively easily been avoided by
providing an efficient stack-pointer-relative addressing mode. Having a
few general-purpose or index registers would have somewhat helped as well.
Philipp
And you'll end up with a low-end Cortex ...
Am 12.10.18 um 20:39 schrieb upsidedown@downunder.com:
On Fri, 12 Oct 2018 10:18:56 +0200, Philipp Klaus Krause <pkk@spth.de>
wrote:
Am 10.10.2018 um 03:05 schrieb Clifford Heath:
<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...
Clifford Heath
They even make dual-core variants (the part where the first digit in the >>> part number is '2'). It seems program counter, stack pointer, flag
register and accumulator are per-core, while the rest, including the ALU >>> is shared. In particular, the I/O registers are also shared, which means >>> some multiplier registers would also be - but currently all variants
with integrated multiplier are single-core.
Use of the ALU is shared byt he two cores, alternating by clock cycle.
Philipp
Interesting, that would make it easy to run a multitasking RTOS
(foreground/background) monitor, which might justify the use of some
reentrant library routines :-). But in reality, the available memory
(ROM/RAM) is so small so that you could easily manage this with static
memory allocations.
But static memory allocation would require one copy of each function per >thread.
And the linker would have to analyze the call graph to always
call the correct function for each thread.
Function pointers get complicated.
Unfortunately, reentrancy becomes even harder with
hardware-multithreading:
TO access the stack, one has to construct a
pointer to the stack location in a memory location.
That memory location
(as any pseudo-registers) is then shared among all running instances of
the function. So it needs to be protected (e.g. with a spinlock), making >access even more inefficient. And that spinlock will cause issues with >interrupts (a solution might be to heavily restrict interrupt routines, >essentially allowing not much more than setting some global variables).
The there is the trade-off of using one such memory location per
function vs. per program (the latter reducing memroy usage, but
resulting in less paralellism).
The pseudo-registers one would want to use are not so much a problem for >interrupt routines (they would just need saving and thus increase
interrupt overhead a bit), but for hardware parallelism. Essentially all >access to them would again have to be protected by a spinlock.
All these problems could have relatively easily been avoided by
providing an efficient stack-pointer-relative addressing mode. Having a
few general-purpose or index registers would have somewhat helped as well.
Philipp
But static memory allocation would require one copy of each function per
thread.
For a foreground/background monitor, the worst case would be two
copies of static data, if both threads use the same rubroutine.
And the linker would have to analyze the call graph to always
call the correct function for each thread.
Linker for such small target ?
With such small processor, just track any dependencies manually.
Function pointers get complicated.
Do you really insist of using function pointer with such small
targets?
Unfortunately, reentrancy becomes even harder with
hardware-multithreading:
With two hardware threads, you would need at most two copies of static
data.
TO access the stack, one has to construct a
pointer to the stack location in a memory location.
Why would you want to access the stack ?
The stack is usable for handling return addresses, but I guess that a hardware thread must have its own return address stack pointer.
That memory location
(as any pseudo-registers) is then shared among all running instances of
the function. So it needs to be protected (e.g. with a spinlock), making
access even more inefficient. And that spinlock will cause issues with
interrupts (a solution might be to heavily restrict interrupt routines,
essentially allowing not much more than setting some global variables).
Disabling all interrupts for the duration of some critical operations
is often enough, but of course, the number of instructions executed
during interrupt disabled should be minimized.
Am 08.11.18 um 20:52 schrieb upsidedown@downunder.com:
But static memory allocation would require one copy of each function per >>> thread.
For a foreground/background monitor, the worst case would be two
copies of static data, if both threads use the same rubroutine.
And the linker would have to analyze the call graph to always
call the correct function for each thread.
Linker for such small target ?
Of course. The support routines the compiler uses reside in some
library, the linker links them in if necessary. Also, the larger
variants are not that small, with up to 256 B of RAM and 8 KB of ROM.
One might want to e.g. have one .c file for handling I²", one for the
soft UART, etc.
And the linker would have to analyze the call graph to always
call the correct function for each thread.
Linker for such small target ?
Of course. The support routines the compiler uses reside in some
library, the linker links them in if necessary. Also, the larger
variants are not that small, with up to 256 B of RAM and 8 KB of ROM.
One might want to e.g. have one .c file for handling I²", one for the
soft UART, etc.
A linker is required, if the libraries are (for copyright reasons)
delivered as binary object code only.
However, if the library are delivered as source files and the compiler/assembler has even a rudimentary #include mechanism, just
include those library files you need. With a include or macro
processor with parameter passing, just invoke same include file or
macro twice with different parameters for different static variable instances.
Of course, linkers are also needed, if very primitive compilation
machines are used, such as floppy based Intellecs or Exorcisers. It
could take a day to compile a large program all the way from sources,
with multiple floppy changes to get the final absolute file to a
single floppy, ready to be burnt into EPROMS for an additional hour or
two. In such environment compiling, linking and burning only the
source file changed would speed up program development a lot.
When using a modern PC for compilation, there are no such issues.
On Fri, 12 Oct 2018 22:06:02 +0200, Philipp Klaus Krause <pkk@spth.de>
wrote:
Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com:
The real issue would be the small RAM size.
Devices with this architecture go up to 256 B of RAM (but they then cost
a few cent more).
Philipp
Did you find the binary encoding of various instruction formats, i.e
how many bits allocated to the operation code and how many for the
address field ?
My initial guess was that the instruction word is simple 8 bit opcode
+ 8 bit address, but the bit and word address limits for the smaller
models would suggest that for some op-codes, the op-code field might
be wider than 8 bits and address fields narrower than 8 bits (e.g. bit
and word addressing).
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,097 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 15:17:06 |
| Calls: | 14,089 |
| Files: | 187,110 |
| D/L today: |
146 files (47,201K bytes) |
| Messages: | 2,491,113 |