Ting's EP32 32 Bit Processor IP with eForth eBook is available now and the Project page started

[JUERGEN]

see https://www.amazon.com/dp/B071D3XMPS and https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is running eForth on my desk in a low cost Lattice DevBoard and there has been an ASIC implementation in the past already as google told me

[Paul Rubin]

Nice, a real ASIC?! I hadn't heard that before. Is there more info
around?

Btw you can now get the BBC MicroBit at adafruit.com for about $16 USD
iirc. Sparkfun.com advertises them too, but they're not in stock there
yet.

[JUERGEN]

The link to one article I found regarding EP32 is on the project page further up and if you google EP 32 RISC Core you find more.

Regarding Microbit, we did a Project Page for the Mecrisp installation at https://wiki.forth-ev.de/doku.php/en:projects:microbit:start
and an interesting eBook and print about MicroBit (not Forth) but complementing well, you can find at https://www.amazon.co.uk/BBC-Micro-Tests-Tricks-Secrets/dp/1541200721/ref=asap_bc?ie=UTF8 I am working on Burkhard to tackle Forth as well ...

[rickman]

On 4/21/2017 3:49 AM, JUERGEN wrote:
> see https://www.amazon.com/dp/B071D3XMPS and https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is running eForth on my desk in a low cost Lattice DevBoard and there has been an ASIC implementation in the past already as google told me

Does this processor have any particular purpose or advantage over other
stack processors?

--

Rick C

[Clive Arthur]

It seems it's small, but with a limited instruction set, so some simple
Forth words may take several clock cycles. For example, OR is made with
com pushr com popr and com, which I guess would be

: or
not >r not r> and not
;

Looks a bit tedious, but maybe if you're pushed for space and speed
isn't everything...

Cheers
--
Clive

[Cecil Bayona]

The designer chose to use 5 bits for the instructions but he made
provisions for 6 bits but of course changes are needed to be made to
implement that, it would allow for 64 primitives instead of 32. Still
the most often used words are primitives that execute in one clock, the
"or" happens to be one of instructions left out because the limit with 5
bits.

I intend to make the instruction word 6 bits and add extra primitives,
there is plenty of space in the FPGA left, All the available RAM is not
being used either and that is another change I intend to make when I
finish my current software project.

--
Cecil - k5nwa

[Ilya Tarasov]

пятница, 21 апреля 2017 г., 10:49:46 UTC+3 пользователь JUERGEN написал:

> see https://www.amazon.com/dp/B071D3XMPS and https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is running eForth on my desk in a low cost Lattice DevBoard and there has been an ASIC implementation in the past already as google told me

Like for many soft-core CPU, I see here a lack of system level modelling. Some solutions looks strange and no clear idea for programmer or system designer is stated.

[rickman]

I'm not following. "Small" is pretty much par for the course for stack
processors. Does "small" have a number associated with it?

I wrote my own stack processor back in 2002 ball park. I worked on
alternate designs over the years. I found much of what I had done was
also done by others. There are any number of stack designs around that
are well fleshed out and available for use. Each one has some advantage
even if it only a small one. None are super stars, but nearly all can
be implemented in a fairly small footprint.

--

Rick C

[rickman]

I don't think there is a lot of value in extending the instruction set.
If you look at Koopman's information on instruction set utilization you
will find a small number of instructions will do a good job of
optimizing Forth implementations. Things like using AND to implement OR
will have very little impact on most programs just because the
instruction is used so infrequently.

Usually instruction sets are extended because the designer has a
emotional objection to leaving an instruction out.

--

Rick C

[JUERGEN]

Ilya, could you please point me to another better IP alternative, 32 bit, well documented at a price of $25 ( or even less? ). And with a Forth that runs on it. Thanks

[Ilya Tarasov]

воскресенье, 23 апреля 2017 г., 15:06:42 UTC+3 пользователь JUERGEN написал:

Do you mean 25$ for ASIC, suitable FPGA or core license?

And yes, 32 bit only? What about scalability to 64, 128? And maybe C support as well? :)

[Cecil Bayona]

Reducing instructions just to achieve a certain limit is not right also
for the device use as a general purpose CPU. This device skips some of
the instructions selected by Koopman and Ting in favor of other
instructions that are specialized.

In this case the instruction set does not have all the instructions
desired by the author of the book that includes the "or" instruction in
the minimum set of instructions. Although he discusses that processor at
length he did not design it, it was done at NASA and they might have a
different set of requirements such as fitting in a small ASIC device,
also they added multiply and divide primitives, which could be very
useful in a CPU in a spacecraft. Actually that is useful everywhere but
not often included.

The design is such so that possibly two on them can fit on a Brevia
FPGA, maybe as things get dicey as the FPGA starts getting close to
full. On my Brevia FPGA one CPU used 28% of the logic so two of them is
quite possible, but RAM will be rather limited.

This CPU works well as is, my purpose in expanding the device may not
agree with ours, mine is to use it as a learning project, rather than
start from scratch with no experience. I would add new instructions to
the existing device such as a "or" instruction and a small amount of
other instructions and features. Features that I think about are adding
an additional stack, adding a Index register, and count register for
handling block moves or searches. Not because it needs the extra
hardware but because I want to learn how to do it.

The J1 CPU is a much simpler CPU so I'm not decided if to experiment
with the ep32 or the J1. The J1 CPU has one bit in its instruction
format left undefined it might come in handy to add extra features.
--
Cecil - k5nwa

[JUERGEN]

There is an EP8, an EP16, the EP32 talked about here and as well an EP64. An alternative to EP32 would be of interest - scalable is a possibility - but from my side the additional Forth and running in a low cost FPGA Board is more important. I assume though, that 16 Bit might be the biggest market.
Best would be a processor, where each Forth Word is VHDL, or as many as possible but I assume this is asked too much, but for the sake of it I assume it has been done - until the FPGA is full ...

[Ilya Tarasov]

воскресенье, 23 апреля 2017 г., 21:24:14 UTC+3 пользователь JUERGEN написал:

Near 2005 my team occasionally switch to my Forth-CPU for almost all projects. This happens because FPGA is cheaper than MCU+FPGA and Forth CPU is easy to use compared with Xilinx Microblaze. Of course, I cannot run Linux, but for most task in low-cost FPGA Forth is perfect.

I count generations of 'mainstream' Forth CPUs. 5th gen is actual for now with 20+ projects completed. Here is hardware supported commands, you can see it is just a VHDL snippet.

constant cmdNOP : integer := 0;

constant cmdNOT : integer := 1;
constant cmdFETCH : integer := 2;
constant cmdSHL : integer := 3;
constant cmdSHR : integer := 4;
constant cmdSHRA : integer := 5;
constant cmdINPORT : integer := 6;

constant cmdSWAP : integer := 7;

constant cmdDUP : integer := 8;
constant cmdOVER : integer := 9;
constant cmdFROMR : integer := 10;
constant cmdLOOP : integer := 11;
constant cmdSYSREG : integer := 12;

constant cmdPLUS : integer := 13;
constant cmdMINUS : integer := 14;
constant cmdAND : integer := 15;
constant cmdOR : integer := 16;
constant cmdXOR : integer := 17;
constant cmdEQUAL : integer := 18;
constant cmdLESSER : integer := 19;
constant cmdGREATER : integer := 20;
constant cmdMULT : integer := 21;

constant cmdDROP : integer := 22;
constant cmdJMP : integer := 23;
constant cmdCALL : integer := 24;
constant cmdRJMP : integer := 25;
constant cmdTOR : integer := 26;

constant cmdSTORE : integer := 27;
constant cmdDO : integer := 28;

constant cmdRIF : integer := 29;
constant cmdUNTIL : integer := 30;

constant cmdRET : integer := 31;
--------------------------------------

For my latest core (7th gen) goto for some pictures to
http://fforum.winglion.ru/viewtopic.php?f=3&t=3104

From the 5th gen all cores are scalable by datawidth, so 8, 16, 32 or 64 (or 24 if you want) will not break schematic.

I don't need 25$ FPGA for this, lowest cost Spartan-6LX4 (10$) is enough, with a half of space for user peripheral.

[rickman]

I'm not clear on your use of Ting as an instruction set reference. What
reference are you citing exactly? My understanding is that this CPU
design was originally by Ting, but maybe I got that wrong.

I assume you are referring to Koopman's book, "Stack Computers the new
wave"?

> In this case the instruction set does not have all the instructions
> desired by the author of the book that includes the "or" instruction in
> the minimum set of instructions. Although he discusses that processor at
> length he did not design it, it was done at NASA and they might have a
> different set of requirements such as fitting in a small ASIC device,
> also they added multiply and divide primitives, which could be very
> useful in a CPU in a spacecraft. Actually that is useful everywhere but
> not often included.

I don't see a "minimum" set of instructions in Koopman's book. He lists
a lengthy glossary of Forth words which are not the same as CPU
instructions and an instruction frequency list of Forth words which does
not have the OR word listed with even a 2% frequency in any cases.

> The design is such so that possibly two on them can fit on a Brevia
> FPGA, maybe as things get dicey as the FPGA starts getting close to
> full. On my Brevia FPGA one CPU used 28% of the logic so two of them is
> quite possible, but RAM will be rather limited.
>
> This CPU works well as is, my purpose in expanding the device may not
> agree with ours, mine is to use it as a learning project, rather than
> start from scratch with no experience. I would add new instructions to
> the existing device such as a "or" instruction and a small amount of
> other instructions and features. Features that I think about are adding
> an additional stack, adding a Index register, and count register for
> handling block moves or searches. Not because it needs the extra
> hardware but because I want to learn how to do it.
>
> The J1 CPU is a much simpler CPU so I'm not decided if to experiment
> with the ep32 or the J1. The J1 CPU has one bit in its instruction
> format left undefined it might come in handy to add extra features.

There is no reason why you are limited to any given instruction size in
an FPGA. In fact, I believe the Brevia uses an FPGA with memory that is
a multiple of 9 bits wide. So a 16 bit instruction word leaves 2 memory
bits unused. Unfortunately the iCE40 line of FPGAs only have 8 bit wide
block memory. If I could count on having that 9th bit in all FPGAs I
would hard code it in myself.

One tip that many CPU designs ignore, if you look at the complexity of
the decoding circuit, instructions that use multiple clock cycles
increase greatly that complexity. A 5 or 6 bit instruction with no
timing data is very easy to decode. Add multiple clock cycles and you
add counter bits that increase greatly the decoding logic. This both
consumes resources and adds timing delays. So a CPU design that is
totally single clock cycle is highly desirable. That has been one of
the more difficult goals to meet in my designs because it impacts many
things such as the handling of interrupts and memory access.

--

Rick C

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> Usually instruction sets are extended because the designer has a
> emotional objection to leaving an instruction out.

In an FPGA cpu, I can see some value in leaving unused opcode space so
that the user can add application-specialized instructions. Also, as
Cecil said, it's preferable to implement the instructions in common use,
rather than just the minimal set that can synthesize the common ones.

[Cecil Bayona]

On 4/23/2017 3:14 PM, rickman wrote:
> On 4/23/2017 12:13 PM, Cecil Bayona wrote:
>> On 4/22/2017 11:23 PM, rickman wrote:

>
> I'm not clear on your use of Ting as an instruction set reference. What
> reference are you citing exactly? My understanding is that this CPU
> design was originally by Ting, but maybe I got that wrong.
>

I read recently an article by a University that the name escapes me at
the time that they worked at implementing the ep32 design in an ASIC,
and that original design was done by two NASA engineers. The literature
from Ting does not claim he invented the design but he offered an
implementation of it for the Lattice Brevia. The University article
mentions Ting as someone who had implemented the design in FPGA and had
written software for it.

On the various literature by Ting on eForth he list a minimal set of
primitives to be used in implementing eForth after consideration on his
work and the work of Charles Moore, and Koopman to about 25 to 35 will
be enough to implement eForth, but that is the minimal set, in some of
his works he uses between 60 and 100 primitives depending on the desired
results. For example in his esp8266 eForth he uses 67 primitives to make
it more efficient.

Personal I think 35 are too ffew primitives to make for an efficient
design, it will work but it's not optimal, more like 45 to 60 so that
all the often used works are single clock primitives.

> I assume you are referring to Koopman's book, "Stack Computers the new
> wave"?
>
>
>> In this case the instruction set does not have all the instructions
>> desired by the author of the book that includes the "or" instruction in
>> the minimum set of instructions. Although he discusses that processor at
>> length he did not design it, it was done at NASA and they might have a
>> different set of requirements such as fitting in a small ASIC device,
>> also they added multiply and divide primitives, which could be very
>> useful in a CPU in a spacecraft. Actually that is useful everywhere but
>> not often included.
>
> I don't see a "minimum" set of instructions in Koopman's book. He lists
> a lengthy glossary of Forth words which are not the same as CPU
> instructions and an instruction frequency list of Forth words which does
> not have the OR word listed with even a 2% frequency in any cases.
>
>
>

> There is no reason why you are limited to any given instruction size in
> an FPGA. In fact, I believe the Brevia uses an FPGA with memory that is
> a multiple of 9 bits wide. So a 16 bit instruction word leaves 2 memory
> bits unused. Unfortunately the iCE40 line of FPGAs only have 8 bit wide
> block memory. If I could count on having that 9th bit in all FPGAs I
> would hard code it in myself.

In the epxx designs the memory is used in multiple of 8 bits so on the
Brevia the 9th bit is not used. Taking to ep16 design to 18 bits would
be a nice improvement wit added primitives and a larger addressing
range, 18 bit stacks and registers would extend the dynamic range of
data values four fold a nice improvement. That would limit the design to
FPGAs with 9 bit memory blocks for which there are plenty available.

>
> One tip that many CPU designs ignore, if you look at the complexity of
> the decoding circuit, instructions that use multiple clock cycles
> increase greatly that complexity. A 5 or 6 bit instruction with no
> timing data is very easy to decode. Add multiple clock cycles and you
> add counter bits that increase greatly the decoding logic. This both
> consumes resources and adds timing delays. So a CPU design that is
> totally single clock cycle is highly desirable. That has been one of
> the more difficult goals to meet in my designs because it impacts many
> things such as the handling of interrupts and memory access.
>

The J1 is a nice design in that regard in that it has a ton of
instructions some of them are actually multiple instructions in one work
at no extra cost that run in one clock, some implementations with extra
features use 140 lines of Verilog

--
Cecil - k5nwa

[rickman]

"Common use" varies from app to app of course, but by definition you
don't need more than 32. If usage were evenly distributed (which it
isn't) 32 instructions would each cover about 3% of the instruction
usage. So unless you have a very odd instruction requirement from your
application 32 instructions should be more than enough to cover the more
frequently used ones.

Even with 32 instructions it is hard to pick instructions that are uses
more than 1% of the time. Forth code tends to use a small number of
operations very frequently.

Certainly it is a designer's prerogative to use as many instructions as
desired. But as I indicated, the instructions selected are often an
emotional choice rather than a technically justified decision. That was
one of the more significant lessons I learned in designing my own and
then seeing what others ended up using.

--

Rick C

[rickman]

On 4/23/2017 8:34 PM, Cecil Bayona wrote:
> On 4/23/2017 3:14 PM, rickman wrote:
>> On 4/23/2017 12:13 PM, Cecil Bayona wrote:
>>> On 4/22/2017 11:23 PM, rickman wrote:
>
>>
>> I'm not clear on your use of Ting as an instruction set reference.
>> What reference are you citing exactly? My understanding is that this
>> CPU design was originally by Ting, but maybe I got that wrong.
>>
>
> I read recently an article by a University that the name escapes me at
> the time that they worked at implementing the ep32 design in an ASIC,
> and that original design was done by two NASA engineers. The literature
> from Ting does not claim he invented the design but he offered an
> implementation of it for the Lattice Brevia. The University article
> mentions Ting as someone who had implemented the design in FPGA and had
> written software for it.
>
> On the various literature by Ting on eForth he list a minimal set of
> primitives to be used in implementing eForth after consideration on his
> work and the work of Charles Moore, and Koopman to about 25 to 35 will
> be enough to implement eForth, but that is the minimal set, in some of
> his works he uses between 60 and 100 primitives depending on the desired
> results. For example in his esp8266 eForth he uses 67 primitives to make
> it more efficient.
>
> Personal I think 35 are too ffew primitives to make for an efficient
> design, it will work but it's not optimal, more like 45 to 60 so that
> all the often used works are single clock primitives.

I don't know what you think makes for an "efficient" design and that is
really what is important in determining an instruction set for a CPU.
Personally I think making the implementation simpler is more useful than
including more Forth primitives in the instruction set. But that is the
point, how to weight the two aspects.

In an FPGA design you have the freedom to set the various details of a
design. While the EP32 is an 8 bit data oriented design, other designs
can make more efficient use of the FPGA resources.

>> One tip that many CPU designs ignore, if you look at the complexity of
>> the decoding circuit, instructions that use multiple clock cycles
>> increase greatly that complexity. A 5 or 6 bit instruction with no
>> timing data is very easy to decode. Add multiple clock cycles and you
>> add counter bits that increase greatly the decoding logic. This both
>> consumes resources and adds timing delays. So a CPU design that is
>> totally single clock cycle is highly desirable. That has been one of
>> the more difficult goals to meet in my designs because it impacts many
>> things such as the handling of interrupts and memory access.
>>
> The J1 is a nice design in that regard in that it has a ton of
> instructions some of them are actually multiple instructions in one work
> at no extra cost that run in one clock, some implementations with extra
> features use 140 lines of Verilog

All processors have multiple functional units. How these units are used
in instructions and how they map to Forth instructions vary. I like to
try to keep the multiple functional units busy when possible, but that
requires a less encoded instruction format using more memory for each
instruction. The trick is to make it pay by getting more done in each
instruction.

--

Rick C

[Paul Rubin]

rickman <gnu...@gmail.com> writes:
> If usage were evenly distributed (which it isn't) 32 instructions
> would each cover about 3% of the instruction usage. So unless you
> have a very odd instruction requirement from your application 32
> instructions should be more than enough to cover the more frequently
> used ones.

You have to consider execution frequency and not just how often the
instruction appears in the code. For example, if it's a DSP application
and you don't have a multiplier, your code might call a small subroutine
for multiplication, not changing the static instruction mix much, but
executing a ton of shifts and adds at runtime. Therefore you might
choose to use an FPGA with multiplier blocks and Forth primitives to use
them. For other applications you might not want to commit those
resources. Similarly if you're doing AES encryption, you can make a
combinational circuit from a few hundred LUTs that does it in a few
cycles instead of 1000s of Forth primitives, etc. That's what I mean by
application-specialized instructions.

[Cecil Bayona]

On 4/23/2017 8:52 PM, rickman wrote:
> On 4/23/2017 8:34 PM, Cecil Bayona wrote:
>
> I don't know what you think makes for an "efficient" design and that is
> really what is important in determining an instruction set for a CPU.
> Personally I think making the implementation simpler is more useful than
> including more Forth primitives in the instruction set. But that is the
> point, how to weight the two aspects.
>
>

Some of these CPUs have very limited amount of RAM, part of being
efficient is not having to do multiple instructions to do something
simple, yes it cost more logic, but the device cost the same even if you
use little logic in it, so it might be worthwhile to add
multi-instructions to one primitive when possible, the ep32 uses 28% of
the LUTS on a Brevia 2, but if it used 50% but saved on RAM usage you
end up ahead.

> In an FPGA design you have the freedom to set the various details of a
> design. While the EP32 is an 8 bit data oriented design, other designs
> can make more efficient use of the FPGA resources.
>
>

A change to use the full width of the memory blocks might be worthwhile,
it will need more LUTS but there are plenty not in use, 36 bits gives
you pretty good size integers. On the ep16 18 bits is a nice
improvement, not only bigger integers but also a bigger address range,
although I don't think that is an issue, but one thing to note is the
Brevia 2 has 512KB of 10 ns memory available on the outside which is
quite a bit.

>>> One tip that many CPU designs ignore, if you look at the complexity of
>>> the decoding circuit, instructions that use multiple clock cycles
>>> increase greatly that complexity. A 5 or 6 bit instruction with no
>>> timing data is very easy to decode. Add multiple clock cycles and you
>>> add counter bits that increase greatly the decoding logic. This both
>>> consumes resources and adds timing delays. So a CPU design that is
>>> totally single clock cycle is highly desirable. That has been one of
>>> the more difficult goals to meet in my designs because it impacts many
>>> things such as the handling of interrupts and memory access.
>>>
>> The J1 is a nice design in that regard in that it has a ton of
>> instructions some of them are actually multiple instructions in one work
>> at no extra cost that run in one clock, some implementations with extra
>> features use 140 lines of Verilog
>
> All processors have multiple functional units. How these units are used
> in instructions and how they map to Forth instructions vary. I like to
> try to keep the multiple functional units busy when possible, but that
> requires a less encoded instruction format using more memory for each
> instruction. The trick is to make it pay by getting more done in each
> instruction.
>

The horizontal decoding of the instruction on the J1 makes it possible
to execute multiple instructions in one clock but it uses 16 bits to the
instruction with one of those 16 bits being unused (room for expansion
here). Even the ep32 has room for more simultaneous execution but one
need the full 6 bits to implement more primitives that combine multiple
actions.

I was going to start learning VHDL but looking at some FPGA
implementations I see that Verilog has simpler code although I gather
that VHDL helps prevent a lot of dumb mistakes. So after I finish my
current software project enough to start being useful I will try the J1
in Verilog and see how that works out. Eventually an 18 bit J1 might be
and interesting modification.
--
Cecil - k5nwa

[rickman]

On 4/23/2017 10:59 PM, Cecil Bayona wrote:
> On 4/23/2017 8:52 PM, rickman wrote:
>> On 4/23/2017 8:34 PM, Cecil Bayona wrote:
>>
>> I don't know what you think makes for an "efficient" design and that
>> is really what is important in determining an instruction set for a
>> CPU. Personally I think making the implementation simpler is more
>> useful than including more Forth primitives in the instruction set.
>> But that is the point, how to weight the two aspects.
>>
>>
>
> Some of these CPUs have very limited amount of RAM, part of being
> efficient is not having to do multiple instructions to do something
> simple, yes it cost more logic, but the device cost the same even if you
> use little logic in it, so it might be worthwhile to add
> multi-instructions to one primitive when possible, the ep32 uses 28% of
> the LUTS on a Brevia 2, but if it used 50% but saved on RAM usage you
> end up ahead.

You have a very limited view of the world. LUT counts are not the only
important thing in a design.

Using more bits to allow multiple instructions in one opcode uses more
memory for each opcode. Whether it uses more memory overall depends on
how good a job is done providing useful opcodes and how often
instructions can be paralleled and how well the tools encode such
parallel instructions.

I had looked at providing three independent fields in an instruction to
allow all three execution units in my CPU to run totally in parallel.
But this could only be useful part of the time. The three units are the
data stack unit (with the data path logic), the return stack unit (with
the memory addressing and loop counting logic) and the instruction fetch
unit (which handles all instruction addressing, jumps, calls,
interrupts, etc). These units can only be usefully used in parallel
when they can operate in parallel when operating independently. The
instruction fetch unit typically just fetches the next instruction or it
can do jumps, calls and returns, but not when the return stack unit is
doing anything else. The return stack unit can do looping control or
address memory, but not when it is being accessed by the data unit. You
get the idea.

In the end getting parallelism to be useful was hard and getting the
tools to generate useful code would have been beyond my current skills
other than manually using assembly language. As a way to improve the
throughput this might be worthwhile. I don't see this as especially
useful for reducing code size and in fact likely would use more memory
for program storage.

>> In an FPGA design you have the freedom to set the various details of a
>> design. While the EP32 is an 8 bit data oriented design, other
>> designs can make more efficient use of the FPGA resources.
>>
>>
> A change to use the full width of the memory blocks might be worthwhile,
> it will need more LUTS but there are plenty not in use, 36 bits gives
> you pretty good size integers. On the ep16 18 bits is a nice
> improvement, not only bigger integers but also a bigger address range,
> although I don't think that is an issue, but one thing to note is the
> Brevia 2 has 512KB of 10 ns memory available on the outside which is
> quite a bit.

You seem to think LUT usage is paramount. I've never found a CPU design
to be overly demanding on the LUT count. More important to me is
getting it to run fast, usually so it will run with the existing system
clock rather than running at a slower clock. The throughput of a small
CPU is often not a problem although that depends entirely on the task at
hand. My point is if you really are counting on the speed being X, then
if it falls a bit short you are hosed. I much prefer to have lots of
excess speed so it is never an issue. Speed is a PITA to deal with if
you are squeezed.

External memory is never required for my CPU designs other than as
interfaces to the system. If you need more than a few kB for program
storage you are going to spend a lot of time writing code. I don't have
that much time usually.

While I find it useful to utilize memory fully when selecting
instruction widths, I don't limit my data or address size. If I need 19
bit addresses I use 19 bit addresses. My CPU design is pretty much N
bits. The only complication is addressing bytes. For data paths that
are multiples of 8 or 9 bits I use 8 or 9 bit bytes. I haven't needed
anything else as yet.

The J1 has very limited support for multiple "instructions" in a single
opcode. Meanwhile it is using a full 16 bits for each instruction. It
does manage to have higher code density than the Xilinx MicroBlaze CPU.

> I was going to start learning VHDL but looking at some FPGA
> implementations I see that Verilog has simpler code although I gather
> that VHDL helps prevent a lot of dumb mistakes. So after I finish my
> current software project enough to start being useful I will try the J1
> in Verilog and see how that works out. Eventually an 18 bit J1 might be
> and interesting modification.

I have used Verilog but do not call myself a Verilog programmer. I
don't know that VHDL strong typing is such a boon to error catching. I
think it is a big PITA when learning, but once you get the hang of
explicit type indication and conversions (and a few other things VHDL
forces you to do) I believe it is more the mindset that helps to prevent
errors. I don't know this isn't possible in Verilog as well.

The main difference is in the test bench facility I think. VHDL lets
you write very good test benches while I've been told you need to use
System Verilog to more easily write good test benches in Verilog.

--

Rick C

[JUERGEN]

Thanks Ilya. For me the easy core availability is important. From Ting you can buy the complete VHDL plus the eForth documentation for $25 - the Brevia or other is separate. We just used the Brevia as it is relatively low cost and a lot of external memory.
What in comparison is the price of your VHDL and documentation in English - or is your product only for internal usage for your projects?

[Ilya Tarasov]

> You seem to think LUT usage is paramount. I've never found a CPU design
> to be overly demanding on the LUT count.

You seem to estimate this based on Lattice chips. Leading architecture now represented by Xilinx and Altera FPGAs, and LUT is combined with 2 flip-flops. Since LUT has 6 inputs, but data is usually wider, several LUTs are required before result may be stored into flip-flop. For CPU designs LUTs are consumed more agressively than flip-flops.

Dedicated resources (RAM, multipliers) are other side of project and should npt be directly compared with LUTs. Coefficient of LUT+FF pair is calculated separately by FPGA CAD and it is not so high (30% or so) for CPU designs. More flip-flops required for heavily pipelined designs, such as DSP and network processing.

> More important to me is
> getting it to run fast, usually so it will run with the existing system
> clock rather than running at a slower clock. The throughput of a small
> CPU is often not a problem although that depends entirely on the task at
> hand. My point is if you really are counting on the speed being X, then
> if it falls a bit short you are hosed. I much prefer to have lots of
> excess speed so it is never an issue. Speed is a PITA to deal with if
> you are squeezed.

Speed != performance. Having CPU in the datapath means a bottleneck. With FPGA you can implement parallel processing by independent datapaths, based on DSP and/or logic cells, and it is extremely faster than read-calculate-write data by CPU.

> > I was going to start learning VHDL but looking at some FPGA
> > implementations I see that Verilog has simpler code although I gather
> > that VHDL helps prevent a lot of dumb mistakes. So after I finish my
> > current software project enough to start being useful I will try the J1
> > in Verilog and see how that works out. Eventually an 18 bit J1 might be
> > and interesting modification.
>
> I have used Verilog but do not call myself a Verilog programmer. I
> don't know that VHDL strong typing is such a boon to error catching. I
> think it is a big PITA when learning, but once you get the hang of
> explicit type indication and conversions (and a few other things VHDL
> forces you to do) I believe it is more the mindset that helps to prevent
> errors. I don't know this isn't possible in Verilog as well.
>
> The main difference is in the test bench facility I think. VHDL lets
> you write very good test benches while I've been told you need to use
> System Verilog to more easily write good test benches in Verilog.

Self-driven system testbench is dramatically better approach. In general, you need just download memory image and provide clk stimulus. Thanks to Forth - VHDL/Verilog model of memory can be exported very easily directly from cross-compiler. After this you can observe all signals, generated by CPU running this program.

[Ilya Tarasov]

понедельник, 24 апреля 2017 г., 9:43:37 UTC+3 пользователь JUERGEN написал:

I'm not too optimistic about this business model. From my point of view, I can spend a lot of time explaining why I did a certain part by certain way. I suppose this is a reason why Xilinx don't provide sources for Microblaze CPU. Many aspects of FPGA RTL coding are not so clear and trade-offs should be made. However, some users want to 'optimize' Microblaze, even if their optimization is worse from system view.

I see the same situation with Forth and Forth CPU. Many peoples ask me for opening my Quark Forth sources. When I ask them 'why do you want it?', they telling me stories about optimization, promotion by team, ANS compatibility etc. - but not about their projects. It is better to explain them how to write and optimized Forth and continue to live with it. Similarly, I prefer to provide a methodology of custom CPU design rather than just throwing a large portion of VHDL to Internet and waiting for followers.

If you have, say, Avnet Microboard or other popular Xilinx board, I can generate a bitstream for you. Now I can see prices for Xilinx are half with comparable logic density. If you have a project, I prefer to give you bitstream for free and see what happens. 25$ is not a money I'm worried about :)

[JUERGEN]

Ilya, I am promoting Forth - for example with the Bookshelf see https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM ; after Forth SW I published the 1802 system, and more recently EP32.
I do not do Custom projects - would send the to the companies that do these projects professionally like Westwood Rock or others. The do A
The RTX2010 still seems to be the best Forth CPU - completely predictable behaviour.
If I interpret your answers, you are working like a consultancy as well. I will come back when there is a project needing such a CPU you have. Which Forth are you using with it?

[Cecil Bayona]

On 4/24/2017 1:20 AM, rickman wrote:
> On 4/23/2017 10:59 PM, Cecil Bayona wrote:
>> On 4/23/2017 8:52 PM, rickman wrote:

>> Some of these CPUs have very limited amount of RAM, part of being
>> efficient is not having to do multiple instructions to do something
>> simple, yes it cost more logic, but the device cost the same even if you
>> use little logic in it, so it might be worthwhile to add
>> multi-instructions to one primitive when possible, the ep32 uses 28% of
>> the LUTS on a Brevia 2, but if it used 50% but saved on RAM usage you
>> end up ahead.
>
> You have a very limited view of the world. LUT counts are not the only
> important thing in a design.

Maybe because LUTS and RAM is all that is inside the FPGA, so one must
utilize them well. A more complex design requires more LUTs in order to
have speed by parallelism, wider CPU words require more LUTS of which
there is a finite number, use the FPGA too densely and then you start
getting timing issues unless you manually place everything for optimum
speed not an easy task for a beginner.

My knowledge is based on what I have read, not what I have done so I
have to rely on what the experts say. I also have a limited budget so
buying huge FPGA Development system is out, so I use small cheap devices
such as the Brevia2 that gives me a lot of features for low dollars but
with finite resources.

When I say RAM I'm talking about program RAM, some of these designs do
not have much Program RAM the ep32 and the J1 are examples of that. I
intend to write complex software for them not hand assemble of a couple
of operations and that is why I'm working first on a Forth compiler that
is easily adaptable to create code for various machines because
otherwise on any customized CPU there is no software available from
anyone else and a CPU is useless without Development Software.

Try to encourage me instead of discouraging me, and once the compiler is
finished I might make a special version for your CPU.

>
> Using more bits to allow multiple instructions in one opcode uses more
> memory for each opcode. Whether it uses more memory overall depends on
> how good a job is done providing useful opcodes and how often
> instructions can be paralleled and how well the tools encode such
> parallel instructions.
>

Not necessarily depends on your instruction encoding, the J1 uses
horizontal encoding, more features and parallel operations means more
program RAM, the ep32 is not horizontal, it uses 6 bits to an
instruction except for a few cases, within those 6 bits there are many
unused opcodes, so adding opcodes does not increase Program Ram usage
but decreases it because an optimizing compiler can take advantage of
those extra instructions to cut down the program size.

There are many options and there isn't just one way to do it.

--
Cecil - k5nwa

[rickman]

On 4/24/2017 7:04 AM, Ilya Tarasov wrote:
>> You seem to think LUT usage is paramount. I've never found a CPU
>> design to be overly demanding on the LUT count.
>
> You seem to estimate this based on Lattice chips. Leading
> architecture now represented by Xilinx and Altera FPGAs, and LUT is
> combined with 2 flip-flops. Since LUT has 6 inputs, but data is
> usually wider, several LUTs are required before result may be stored
> into flip-flop. For CPU designs LUTs are consumed more agressively
> than flip-flops.

I have no idea what you are talking about. I've said nothing about a
size of LUT or how they are bungled with FFs.

> Dedicated resources (RAM, multipliers) are other side of project and
> should npt be directly compared with LUTs. Coefficient of LUT+FF pair
> is calculated separately by FPGA CAD and it is not so high (30% or
> so) for CPU designs. More flip-flops required for heavily pipelined
> designs, such as DSP and network processing.

Yes, this is all obvious.

Ting took the "functional" simulation approach and ran his 8080 design
with a Forth program. I wanted to illustrate the use of test benches on
his design and constructed a simple test with just 10 instructions or
fewer. I found a bug in his 8080 implementation that wasn't caught in
his functional test because it wasn't constructed to thoroughly test the
CPU.

Testing is not just running the design. Tests have to be constructed to
test a design rather than just running it.

--

Rick C

[rickman]

On 4/24/2017 1:20 PM, Cecil Bayona wrote:
> On 4/24/2017 1:20 AM, rickman wrote:
>> On 4/23/2017 10:59 PM, Cecil Bayona wrote:
>>> On 4/23/2017 8:52 PM, rickman wrote:
>
>>> Some of these CPUs have very limited amount of RAM, part of being
>>> efficient is not having to do multiple instructions to do something
>>> simple, yes it cost more logic, but the device cost the same even if you
>>> use little logic in it, so it might be worthwhile to add
>>> multi-instructions to one primitive when possible, the ep32 uses 28% of
>>> the LUTS on a Brevia 2, but if it used 50% but saved on RAM usage you
>>> end up ahead.
>>
>> You have a very limited view of the world. LUT counts are not the
>> only important thing in a design.
>
> Maybe because LUTS and RAM is all that is inside the FPGA, so one must
> utilize them well. A more complex design requires more LUTs in order to
> have speed by parallelism, wider CPU words require more LUTS of which
> there is a finite number, use the FPGA too densely and then you start
> getting timing issues unless you manually place everything for optimum
> speed not an easy task for a beginner.

You seem to be repeating the same thought, that LUT count is paramount.
There are many aspects to a good design and LUT usage is just one.
Everything in life is finite including time.

Timing issues are more likely caused by the logic requiring too many
layers than a crowded part. But timing is a design goal and you only
need to meet your requirement.

Hand placement doesn't automatically improve timing. Placement is a
hugely complex task. If the structure is very (with the emphasis on
*very*) simple, hand placement can optimize timing. Otherwise you will
find moving one thing to improve timing can make three things worse.

> My knowledge is based on what I have read, not what I have done so I
> have to rely on what the experts say. I also have a limited budget so
> buying huge FPGA Development system is out, so I use small cheap devices
> such as the Brevia2 that gives me a lot of features for low dollars but
> with finite resources.

The LFXP2-5E in the Brevia 2 board has 5000 LUTs. If you get anywhere
near using all of them you are likely not getting an efficient
synthesis. My 16/18 bit stack processor was only a few hundred LUTs.
Don't worry about things you don't need to worry about.

> When I say RAM I'm talking about program RAM, some of these designs do
> not have much Program RAM the ep32 and the J1 are examples of that. I
> intend to write complex software for them not hand assemble of a couple
> of operations and that is why I'm working first on a Forth compiler that
> is easily adaptable to create code for various machines because
> otherwise on any customized CPU there is no software available from
> anyone else and a CPU is useless without Development Software.
>
> Try to encourage me instead of discouraging me, and once the compiler is
> finished I might make a special version for your CPU.

Sorry if I sound like I am trying to discourage you. I'm just trying to
help you not waste time in ineffective areas.

Certainly I could use help with compiling. I basically wrote an
assembler which was idiot simple as the opcodes were mapped 1 to 1 to
the mnemonics for the most part. The only instructions with variable
fields were the literal and the jump/call. Oddly enough the jump/call
gave me trouble. It uses PC relative addressing and when jumping
backwards across the instruction there was a variable length of
instructions to build the address. The value to be compiled would
affect the starting address and so the value needing to be compiled. In
the end I found if I just calculated the address twice it would work.
But I was never happy with that.

A new approach I would be interested in exploring combines a register
oriented instruction set with a stack design by using register numbers
to operate on values not at the top of the stack. Combined with a
variable number of items for push/pop and it can eliminate most stack
juggling operations. I suppose some would view this as "combining"
multiple instructions. I don't have a clue as to mapping this to a
Forth model.

>> Using more bits to allow multiple instructions in one opcode uses more
>> memory for each opcode. Whether it uses more memory overall depends
>> on how good a job is done providing useful opcodes and how often
>> instructions can be paralleled and how well the tools encode such
>> parallel instructions.
>>
>
> Not necessarily depends on your instruction encoding, the J1 uses
> horizontal encoding, more features and parallel operations means more
> program RAM, the ep32 is not horizontal, it uses 6 bits to an
> instruction except for a few cases, within those 6 bits there are many
> unused opcodes, so adding opcodes does not increase Program Ram usage
> but decreases it because an optimizing compiler can take advantage of
> those extra instructions to cut down the program size.

That's because the extra bit has already been allocated and the space
used. *How much* can the program size be reduced by using extra
opcodes? The point is fancy features don't get used so often and so
provide small gains to program size or speed. That's why Koopman's book
is useful.

I don't remember who, but I think someone has published a list of Forth
idioms that can be used to optimize code. But they often require
multiple operations and so can't be done in a single clock cycle.
Single cycle operation of all instructions is a primary objective in my
designs. Multi-cycle operation complicates the CPU in many ways making
it less efficient by most measures.

> There are many options and there isn't just one way to do it.

Nope, there isn't just one way. But trends are trends and it is very
enlightening to explore a variety of spaces without digging in any too
deep. Learn the trends without focusing on any and you will see most of
the things that look like good ideas won't be significant improvements.

--

Rick C

[rickman]

On 4/24/2017 7:16 AM, Ilya Tarasov wrote:
>
> If you have, say, Avnet Microboard or other popular Xilinx board, I can generate a bitstream for you. Now I can see prices for Xilinx are half with comparable logic density. If you have a project, I prefer to give you bitstream for free and see what happens. 25$ is not a money I'm worried about :)

Do you have documentation for using your cores? I can't see plugging a
bitstream into an FPGA without having some form that can be compiled
with my code. Using an FPGA for a CPU without being able to add to that
FPGA is not any improvement over a standalone CPU. MCU/CPUs are highly
optimized and provide very good platforms for running Forth. The
purpose of rolling a CPU into an FPGA is to add to that design to fully
utilize the FPGA as an FPGA.

--

Rick C

[Cecil Bayona]

Arrg... I give up, I know nothing, you know it all, not point here.

By the way where are your CPU designs published? I would like to look at
a perfect design.

--
Cecil - k5nwa

[rickman]

Sorry I bothered you.

--

Rick C

[Ilya Tarasov]

понедельник, 24 апреля 2017 г., 16:18:55 UTC+3 пользователь JUERGEN написал:

> Ilya, I am promoting Forth - for example with the Bookshelf see https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM ; after Forth SW I published the 1802 system, and more recently EP32.
> I do not do Custom projects - would send the to the companies that do these projects professionally like Westwood Rock or others. The do A
> The RTX2010 still seems to be the best Forth CPU - completely predictable behaviour.
> If I interpret your answers, you are working like a consultancy as well. I will come back when there is a project needing such a CPU you have. Which Forth are you using with it?

We usually provide early estimation of projects based on Xilinx FPGA. We also has our own products and prefer to use Forth-processors inside. Consultancy is possible of course. My base Forth is Quark-Forth. I target applications with floating point, 3D graphics (for modelling) and some cross-compilation. Other Forth may be used, of course.

[Ilya Tarasov]

понедельник, 24 апреля 2017 г., 20:21:02 UTC+3 пользователь Cecil - k5nwa написал:

> On 4/24/2017 1:20 AM, rickman wrote:
> > On 4/23/2017 10:59 PM, Cecil Bayona wrote:
> >> On 4/23/2017 8:52 PM, rickman wrote:
>
> >> Some of these CPUs have very limited amount of RAM, part of being
> >> efficient is not having to do multiple instructions to do something
> >> simple, yes it cost more logic, but the device cost the same even if you
> >> use little logic in it, so it might be worthwhile to add
> >> multi-instructions to one primitive when possible, the ep32 uses 28% of
> >> the LUTS on a Brevia 2, but if it used 50% but saved on RAM usage you
> >> end up ahead.
> >
> > You have a very limited view of the world. LUT counts are not the only
> > important thing in a design.
>
> Maybe because LUTS and RAM is all that is inside the FPGA, so one must
> utilize them well. A more complex design requires more LUTs in order to
> have speed by parallelism, wider CPU words require more LUTS of which
> there is a finite number, use the FPGA too densely and then you start
> getting timing issues unless you manually place everything for optimum
> speed not an easy task for a beginner.
>
> My knowledge is based on what I have read, not what I have done so I
> have to rely on what the experts say. I also have a limited budget so
> buying huge FPGA Development system is out, so I use small cheap devices
> such as the Brevia2 that gives me a lot of features for low dollars but
> with finite resources.

Take a look on Arty board. It is 99$, but has 35K logic cells vs 5K in Lattice.

> When I say RAM I'm talking about program RAM, some of these designs do
> not have much Program RAM the ep32 and the J1 are examples of that. I
> intend to write complex software for them not hand assemble of a couple
> of operations and that is why I'm working first on a Forth compiler that
> is easily adaptable to create code for various machines because
> otherwise on any customized CPU there is no software available from
> anyone else and a CPU is useless without Development Software.
>
> Try to encourage me instead of discouraging me, and once the compiler is
> finished I might make a special version for your CPU.

Don't listen those who wants to discourage you. CPU design is not a mystical skill for chosens. It is impossible to seriously discuss CPU details before you will have 5 designs done. Start from the simplest design and make it working. Command encoding and pipeline optimization often represent a false path without proper experience and understanding pipeline really good. Btw, stack machine is easy to understand and implement in VHDL, if you familiar with Forth.

[Ilya Tarasov]

понедельник, 24 апреля 2017 г., 20:40:11 UTC+3 пользователь rickman написал:

> On 4/24/2017 7:04 AM, Ilya Tarasov wrote:
> >> You seem to think LUT usage is paramount. I've never found a CPU
> >> design to be overly demanding on the LUT count.
> >
> > You seem to estimate this based on Lattice chips. Leading
> > architecture now represented by Xilinx and Altera FPGAs, and LUT is
> > combined with 2 flip-flops. Since LUT has 6 inputs, but data is
> > usually wider, several LUTs are required before result may be stored
> > into flip-flop. For CPU designs LUTs are consumed more agressively
> > than flip-flops.
>
> I have no idea what you are talking about. I've said nothing about a
> size of LUT or how they are bungled with FFs.

Nothing good. This probably means you have no detailed understanding of FPGA
architecture.

> > Dedicated resources (RAM, multipliers) are other side of project and
> > should npt be directly compared with LUTs. Coefficient of LUT+FF pair
> > is calculated separately by FPGA CAD and it is not so high (30% or
> > so) for CPU designs. More flip-flops required for heavily pipelined
> > designs, such as DSP and network processing.
>
> Yes, this is all obvious.

Really? In this kind you should have your own observation about resources required for different types of designs.

> > Self-driven system testbench is dramatically better approach. In
> > general, you need just download memory image and provide clk
> > stimulus. Thanks to Forth - VHDL/Verilog model of memory can be
> > exported very easily directly from cross-compiler. After this you can
> > observe all signals, generated by CPU running this program.
>
> Ting took the "functional" simulation approach and ran his 8080 design
> with a Forth program. I wanted to illustrate the use of test benches on
> his design and constructed a simple test with just 10 instructions or
> fewer. I found a bug in his 8080 implementation that wasn't caught in
> his functional test because it wasn't constructed to thoroughly test the
> CPU.
>
> Testing is not just running the design. Tests have to be constructed to
> test a design rather than just running it.

You missing the point completely. Construct tests whenever you want, but when I construct tests, I don't need to edit a single line in VHDL or Verilog. All tests are just programs in Forth (or Assembler), compiles by Forth cross-compiler and runs automatically by single self-driven testbench. All stimulus are comes from cross-compiler, and don't needed to be coded in VHDL.

[Cecil Bayona]

There is only one site for Quak-Forth and my anti-virus thinks its a
site with Malware, I went to it anyway and its in Russian but the second
I clicked on a link, it informed me that it was disinfecting my PC due
to Malware.

--
Cecil - k5nwa

[Ilya Tarasov]

понедельник, 24 апреля 2017 г., 21:28:31 UTC+3 пользователь rickman написал:

All cores has UART for programming, embedded directly into core. USB-UART converters are common now, so having USB port is enough. For final production you need sorce texts, of course. We have all sources, our customers don't ask for recompiling. It was enough so far.

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 1:00:59 UTC+3 пользователь Cecil - k5nwa написал:

I know :( I'm not alone who meets this problem. We suppose this is because of words like EXECUTE, jumping to unknown address. Usually I got antivirus message right after compiling Quark with Fasm :) If you was at www.msyst.ru , this is definitely correct archive.

[Cecil Bayona]

Thanks, the Arty gives you a lot for the money and I have read that its
fast, I'll start saving my pennies.

I have already tried four different CPUs designed by someone else, ep16,
ep32, PDP1, i8080 next I want to try the J1, I want to make some small
changes to it after it works, it's available in VHDL and Verilog, the
original design was in Verilog. I have an optimized version that is 140
lines of Verilog, looking at it I can see that its very simple language.

I keep being undecided on which language to learn, Verilog looks simple,
VHDL has a lot of error checking, I'm not ready yet to start learning as
I'm in the middle of a software project having to do with FPGA CPUs but
maybe in a couple of Month I will be ready.

What tools do you use with the Xilinx FPGA Vivado, ISE WebPack, or
something else?



--
Cecil - k5nwa

[rickman]

There must be a large language barrier. I said nothing about editing
your HDL code.

--

Rick C

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 1:22:20 UTC+3 пользователь rickman написал:

Did you ever understood what I'm talking about? Tell me about testbenches and write an example how do you plan to test CPU with VHDL or Verilog.

[Ilya Tarasov]

> Thanks, the Arty gives you a lot for the money and I have read that its
> fast, I'll start saving my pennies.

No matter, you can use what you feel better for you.

> I have already tried four different CPUs designed by someone else, ep16,
> ep32, PDP1, i8080 next I want to try the J1, I want to make some small
> changes to it after it works, it's available in VHDL and Verilog, the
> original design was in Verilog. I have an optimized version that is 140
> lines of Verilog, looking at it I can see that its very simple language.
>
> I keep being undecided on which language to learn, Verilog looks simple,
> VHDL has a lot of error checking, I'm not ready yet to start learning as
> I'm in the middle of a software project having to do with FPGA CPUs but
> maybe in a couple of Month I will be ready.

Verilog is often compared with C, and VHDL is very close to Ada. VHDL code is larger and considered as complex. However it is well structured and you will always been prompted when forgot to complete operands. Also, VHDL don't allows automatic type casting, and this is not bad at the early stage.

From my teaching experince, VHDL->Verilog is better than Verilog->VHDL, if you plan to learn both languages.

> What tools do you use with the Xilinx FPGA Vivado, ISE WebPack, or
> something else?

ISE must be used for Spartan-6, because Vivado can support Xilinx FPGA started from the 7 series. Vivado is current CAD and has free version too. For 7 series FPGA you can use both ISE and Vivado.

[Cecil Bayona]

On 4/24/2017 5:10 PM, Ilya Tarasov wrote:
> вторник, 25 апреля 2017 г., 1:00:59 UTC+3 пользователь Cecil - k5nwa написал:

>> There is only one site for Quak-Forth and my anti-virus thinks its a
>> site with Malware, I went to it anyway and its in Russian but the second
>> I clicked on a link, it informed me that it was disinfecting my PC due
>> to Malware.
>
> I know :( I'm not alone who meets this problem. We suppose this is because of words like EXECUTE, jumping to unknown address. Usually I got antivirus message right after compiling Quark with Fasm :) If you was at www.msyst.ru , this is definitely correct archive.
>

Yes, that is the site, quite a few Forth are flagged by Anti-Virus
software as Malware when they are not.

--
Cecil - k5nwa

[rickman]

Provide me with the code for the interfaces.

--

Rick C

[rickman]

Or you can view the SVFIG monthly meeting a few months ago where Ting
presented his 8080 model and read my pages on testing it via a test
bench. I expect I would do something like that for nearly any processor.

--

Rick C

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 1:43:34 UTC+3 пользователь Cecil - k5nwa написал:

I can rebuild Quark from source and send you immediately. With hangouts, for example.

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 1:44:45 UTC+3 пользователь rickman написал:

You don't need interface. With properly approach you need only this:

-- Clock process definitions
clk_process :process
begin
clk <= '0';
wait for clk_period/2;
clk <= '1';
wait for clk_period/2;
end process;


-- Stimulus process
stim_proc: process
begin
reset <= '1';
wait for clk_period;
reset <= '0';

wait;
end process;

[rickman]

Great! So I don't really need to even simulate it. I know exactly what
this code will do. Thanks a lot!

--

Rick C

[Cecil Bayona]

Thanks for the offer, is there any documentation in English? Is the
source available?

The site is in Russian but my browser would not translate it so it was
interesting translating line by line, not very practical, I'll have to
try a different browser and see if it translated the whole page.

In any case I gathered it has characters, 32 bit integers, and floats, I
found a PDF manual but again it was in Russian which is natural for you
but rather useless for me so without documentation I wonder how could I
use it.

I'm trying to write my own Forth and I will need to look at the settings
for the Go compiler as an int is 64 bits by default, it is cranking out
code for a 64 bit CPU which is what the host machine is. Its going to be
a Windows Forth for the first iteration so it doesn't hurt much of
anything as my desktops have a minimum of 16 GB of RAM. It might become
a problem when generating code for a target machine, I have not though
much about it presently.

--
Cecil - k5nwa

[Mark Wills]

On Monday, 24 April 2017 23:19:29 UTC+1, Cecil - k5nwa wrote:
> I keep being undecided on which language to learn, Verilog looks simple,
> VHDL has a lot of error checking, I'm not ready yet to start learning as
> I'm in the middle of a software project having to do with FPGA CPUs but
> maybe in a couple of Month I will be ready.
>

I'm in exactly the same place as you. I'm leaning more towards Verilog because
it looks easier to understand.

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 3:36:45 UTC+3 пользователь rickman написал:

> > You don't need interface. With properly approach you need only this:
> >
> > -- Clock process definitions
> > clk_process :process
> > begin
> > clk <= '0';
> > wait for clk_period/2;
> > clk <= '1';
> > wait for clk_period/2;
> > end process;
> >
> >
> > -- Stimulus process
> > stim_proc: process
> > begin
> > reset <= '1';
> > wait for clk_period;
> > reset <= '0';
> >
> > wait;
> > end process;
>
> Great! So I don't really need to even simulate it. I know exactly what
> this code will do. Thanks a lot!

And here is a result of simulation :)
http://fforum.winglion.ru/viewtopic.php?f=3&t=3124

Your global mistake you are rely in unit-tests rather than higher level test style. You will know absolutely nothing about whole CPU after running test for register, ALU, system bus etc. Even if unit tests passed ok, connected units may fail because of different interface or cycles mismatching. All these problem may be revealed at integration level testing, then stimulus are applied to connected units, not to every unit one by one. The next step is system level test. If you are so smart, please explain me what is it.

[Clive Arthur]

On 23/04/2017 05:23, rickman wrote:

<snip>

> Things like using AND to implement OR
> will have very little impact on most programs just because the
> instruction is used so infrequently.

Every processor I've ever used (I think) had an 'or' instruction. But
you're right, checking a few kB of recent dsPIC assembler I wrote, I've
used 'or' once, 'and' quite a bit and 'xor' a few times.

Cheers
--
Clive

[Cecil Bayona]

Indecision on my part, every time I'm fairly convinced to go with
Verilog because it looks so straightforward I find comments from experts
that recommend VHDL instead.

It looks like Verilog is a lot easier to understand so my current
thinking is to go ahead and work with it and get some things done then
later at my leisure dwell into VHDL.

I used to design hardware and I miss it, hence FPGAs the hardware
designers dream come true to try out design ideas.

I like simple designs they keep you out of trouble when it comes to CPUs
the concepts in the J1 are a nice starting point it works well but there
are major room for improvements with easy remedies so that will be a
good starting point to get my feet wet. So eventually a J1-2 maybe
although I've read that there is a J2, J3, J4, J5, and a J6 each
progressively more advance by other authors, the J6 is extremely complex
with multiple levels of pipeline. I'm not interested in a J6 if I wanted
that I would use an Intel CPU.

--
Cecil - k5nwa

[rickman]

On 4/25/2017 7:44 AM, Ilya Tarasov wrote:
> вторник, 25 апреля 2017 г., 3:36:45 UTC+3 пользователь rickman написал:
>>> You don't need interface. With properly approach you need only this:
>>>
>>> -- Clock process definitions
>>> clk_process :process
>>> begin
>>> clk <= '0';
>>> wait for clk_period/2;
>>> clk <= '1';
>>> wait for clk_period/2;
>>> end process;
>>>
>>>
>>> -- Stimulus process
>>> stim_proc: process
>>> begin
>>> reset <= '1';
>>> wait for clk_period;
>>> reset <= '0';
>>>
>>> wait;
>>> end process;
>>
>> Great! So I don't really need to even simulate it. I know exactly what
>> this code will do. Thanks a lot!
>
> And here is a result of simulation :)
> http://fforum.winglion.ru/viewtopic.php?f=3&t=3124

Simulation of what? I've only seen a reset line and a clock. The rest
of that is undefined behavior to me. Besides, looking at waveforms is
not a very productive method of test.

> Your global mistake you are rely in unit-tests rather than higher level test style.

"Higher level test style" is a euphemism for functional test which is
not the best way to verify that something meets a spec. But since I
don't have a spec I can't verify a design meets it.

> You will know absolutely nothing about whole CPU after running test for register, ALU, system bus etc. Even if unit tests passed ok, connected units may fail because of different interface or cycles mismatching. All these problem may be revealed at integration level testing, then stimulus are applied to connected units, not to every unit one by one. The next step is system level test. If you are so smart, please explain me what is it.

You are making assumptions for what testing I would do. We call that a
straw man argument. You propose what I would do, then attack it. When
you decide to stop playing the one-upmanship game I'll be happy to talk
to you. I'm not here for a pissing contest.

--

Rick C

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 5:16:52 UTC+3 пользователь Cecil - k5nwa написал:

This is not a simple question about translating. I can read English free enough, but writing is harder (common problem for Russians). If you need certain question to be solved, jut write me. For me. It is very interesting for me how to setup a Forth system for other team or user. I can help you via mail or chat as long as you need it. Maybe in this case we will find most critical things to translate.

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 19:21:51 UTC+3 пользователь Cecil - k5nwa написал:

> On 4/25/2017 3:26 AM, Mark Wills wrote:
> > On Monday, 24 April 2017 23:19:29 UTC+1, Cecil - k5nwa wrote:
> >> I keep being undecided on which language to learn, Verilog looks simple,
> >> VHDL has a lot of error checking, I'm not ready yet to start learning as
> >> I'm in the middle of a software project having to do with FPGA CPUs but
> >> maybe in a couple of Month I will be ready.
> >>
> >
> > I'm in exactly the same place as you. I'm leaning more towards Verilog because
> > it looks easier to understand.
> >
>
> Indecision on my part, every time I'm fairly convinced to go with
> Verilog because it looks so straightforward I find comments from experts
> that recommend VHDL instead.
>
> It looks like Verilog is a lot easier to understand so my current
> thinking is to go ahead and work with it and get some things done then
> later at my leisure dwell into VHDL.

Yes, it is true. But result is predictable - when turning to VHDL, one will need to learn more complex VHDL and design concepts as well. VHDL is not very complex to learn, indeed, it is a question of remembering some code patterns, but after VHDL, Verilog looks easier.

Also, there are some checks performed in VHDL. For example, Verilog provides automatic type casting and signal width alignment. It looks fine, until you got a hidden mistake when you 8-bit bus is connected to 16-bit and all missing bits quietly replaces by zero in Verilog. VHDL will not allow such tricks. It takes slightly more time to type CPU sources, but saves much more at debugging stage.

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 19:41:34 UTC+3 пользователь rickman написал:

Yes, I see you still can't understand an idea I clearly describe above. All functionality provides by program code generated by cross-compiler. When this image of program added to memory model, providing clock signal will start to issue commands one by one. In this case I don't need to type commands and data in VHDL testbench, I just need to fill memory by my program and provide clock model. All CPU signals will be produced automatically.

I'm very glad you find an idea about waveforms. Take a look on assert operator in VHDL and think what else can be provided by Forth cross-compiler. You can search by keywords 'golden output' etc. This should point you to right way.

> > Your global mistake you are rely in unit-tests rather than higher level test style.
>
> "Higher level test style" is a euphemism for functional test which is
> not the best way to verify that something meets a spec. But since I
> don't have a spec I can't verify a design meets it.

I have a program in Forth and test it on PC. Now I know a result. When I copy this text to Forth-CPU IDE, build memory image and copy it to the simulation folder. After several cycles I want to see exactly the same result in the simulator - at the top of stack, for example. What specs?

> > You will know absolutely nothing about whole CPU after running test for register, ALU, system bus etc. Even if unit tests passed ok, connected units may fail because of different interface or cycles mismatching. All these problem may be revealed at integration level testing, then stimulus are applied to connected units, not to every unit one by one. The next step is system level test. If you are so smart, please explain me what is it.
>
> You are making assumptions for what testing I would do. We call that a
> straw man argument. You propose what I would do, then attack it. When
> you decide to stop playing the one-upmanship game I'll be happy to talk
> to you. I'm not here for a pissing contest.

It is your answer, not mine. I suggest to use simple test with automatic stimulus generation, based on Forth-generated data. If you don't understand it, the only possible way for you is to write separate testbenches. This is simple and I don't need to know every line of your code.

[Walter Banks]

I have worked on the development of quite a few commercial ISA's There
is nothing like profiling release versions of intended application code
to start looking at implementation optimization.

Rickman elsewhere pointed out the emotional underlying reason for
instruction space bloat. Koopman as he points out was generally focused
on what is needed.

I worked on on processor design that the compiler would decide the ISA
needed for this specific compile of this specific app. The result was
the compiler could make or / and not choices as an optimizations /
speed. This opened my eyes a lot on just what is actually used in an ISA.

w..

[Cecil Bayona]

Thanks any assistance is welcomed, here is basically what I'm trying to do'

I would like to work and learn to use FPGAs to design simple Stack
Processors but before I begin on that project I need development
software that is easy to modify so I can adapt it to the instruction of
the FPGA CPU. A FPGA CPU without development software is not very useful
so currently I'm writing my own Forth that is simple, and based on eForth.

I've started working on a Forth Virtual Machine based on C although most
likely I will take a detour and first create it in the Go language as a
learning exercise to learn Go which I plan to use for other projects. In
any case the goal is to have Forth software that is easy to modify.

I am flexible on the approach so the use of a decent Forth compiler that
is easy to understand will also work instead of C or Go. Right now in C
I have most of the VM done and I'm close to do final testing with it but
its pretty simple so if I start from scratch with something else it not
a big problem. Forth would be ideal but if I use a Forth compiler it
needs to be simple to understand and modify, be efficient so it should
generate machine code or at least be Direct Threaded, and have source
available so I can feel confident about putting many hours to make it
all work and be able to be on my own if something happens to the
developers of the Forth.

Right now I been using eForth a rather simple version of Forth that is
easy to understand and I have source for various forms of it. I doesn't
generate machine code it's a direct and indirect threaded form of Forth
I have both versions so there is room for improvement there but still
it's easy to work with.

But I'm always keeping an eye out for a better tool, the Windows version
I have of eForth has a flaw in that it does not work reliably with
Windows 10, all my PCs use Windows 10 X64, I had a Windows 7 PC but it
has been converted to Windows 10 recently.

So I want to learn about your Forth, it's features, is source available,
how simple is it so it's understandable?

--
Cecil - k5nwa

[rickman]

I'm a dyed in the wool VHDL guy, but I don't recommend one way or the
other between the two languages. I did not have an easy time learning
VHDL, but the language was not as easy to use in 1995 and learning
resources were not as good. I took a one week course in the CAD package
we selected and they covered VHDL in one day. Not only was that far
insufficient the Orcad VHDL tool was basically dysfunctional. We ended
up switching to the Xilinx tools. Then a month later Xilinx switched
tools and I had to change again. The project got done and I learned a
lot more than I would have preferred.

Now I think the tools are all pretty good and the learning resources are
much better and even the language has greatly improved. VHDL-2008 added
a lot of features that help with all the type conversion stuff. Not all
of it is implemented by every vendor (even 9 years later) but most of it
is available pretty universally.

That said, there is at least one FPGA designer here who swears by
Verilog and has converted an entire team from VHDL by showing them
productivity improvements. Bernd Paysan I tried to argue that once you
learn how to deal with the strong typing of VHDL and use editor
functions to help with the verbose typing of VHDL, it can be easy to
use. But he insisted that he can get much higher productivity in
Verilog and the same for his team. I couldn't show him wrong.

The main reason why I have not switched to Verilog, at least for a try,
is that I know the assumptions that Verilog makes (in contrast to VHDL
requiring you to explicitly state everything) can get you into trouble
somewhat invisibly. I have asked about a good book on Verilog a number
of times (that would clearly identify these pitfalls) and I am always
told none exist. Allegedly all the text books on Verilog pretty well
suck. That comes from the folks in comp.lang.verilog.

Oh yeah, the other reason I haven't switched to Verilog is because with
VHDL you get some pretty good test bench capability. In Verilog you
need to use System Verilog to match those capabilities. Test benches
are actually what HDL coding is all about. It is easy to write a
design, testing is the hard part. Testing on the chip is a *very* hard
way to go. My designs work first time in the chip around 95% of the
time (other than very minor issues) because I spend adequate time in
simulation.

--

Rick C

[Cecil Bayona]

That is what I keep reading about from persons that are quite experience
in using VHDL that is why I keep being undecided. Verilog looks a lot
simpler to learn but I quit using C a long time back because it quietly
lets you do things that will get you in trouble. The experts tend to
think the same thing about Verilog, it's easier to learn up front but
will not protect you from dumb mistakes.

Human nature can often work out against a persons best interest. Take
the quicker route but pay for the rest of your life. Too many persons
with vast experience on FPGAs keep coming up with the same advice it
would most likely be prudent to listen to it and learn the more
difficult approach up front rather than pay for the simpler way many
times over.

I have books on both languages so I will think about it for a month or
two before I have to make a decision.

Thanks for the advice.

--
Cecil - k5nwa

[rickman]

How about not having the AND instruction? The TMS9900 which is still
popular with some FPGA CPU fans has an OR instruction, SOC/SOCB (set
ones corresponding) but the matching pair is SZC/SZCB (set zeros
corresponding) which inverts the mask before anding. There is an
immediate mode and instruction though, ANDI.

But then this is an instruction set from the Rococo era of CPU design.
Considering similar CPU designs from the MISC category you will not find
an OR instruction in the F18A (used in the GA144) in spite of the use of
the OR mnemonic. It is actually an XOR instruction, lol! There is also
no subtract instruction. Subtraction is done by inverting the
subtrahend and adding 1, or sometimes it is easier to invert the minuend
and the difference because there is no SWAP instruction. So few
instructions and yet a very code size efficient design.

Cats don't like CPU instruction sets because there are so many ways they
can get skinned!

--

Rick C

[rickman]

That must have been a pretty complex compiler.

--

Rick C

[rickman]

But if you know these are mistakes, can't you avoid them on your own?

I have used VHDL for so long that I don't even have to think about
avoiding all the compiler complaints, it is pretty automatic. If I knew
the issues to avoid in Verilog I don't think I would have too much
trouble with it.

> Human nature can often work out against a persons best interest. Take
> the quicker route but pay for the rest of your life. Too many persons
> with vast experience on FPGAs keep coming up with the same advice it
> would most likely be prudent to listen to it and learn the more
> difficult approach up front rather than pay for the simpler way many
> times over.

I've never met anyone using Verilog that thought it was a mistake.
Where is Bernd Paysan to weigh in?

> I have books on both languages so I will think about it for a month or
> two before I have to make a decision.

I have one book in *both* languages, "HDL Chip Design" by Douglas J
Smith. It is not organized like a typical text book starting you at the
basics of HDL. It does however, show each example in VHDL and Verilog
side by side. Unless it has been updated for VHDL-2008 it shows
VHDL-1993 as my copy does. I strongly encourage anyone interested in
VHDL to learn VHDL-2008. If you don't, there is little point to using
VHDL, that's how significant the improvements are.

--

Rick C

[rickman]

On 4/25/2017 1:37 PM, Cecil Bayona wrote:
>

> I have books on both languages so I will think about it for a month or
> two before I have to make a decision.

Oh yeah, if you do decide to use VHDL I don't ever want to see you use

if (clk'event and clk '1')

I will hunt you down and burn your house.

I can't believe there are still universities that teach this!!!

I'm not over reacting am I?

--

Rick C

[Lars Brinkhoff]

rickman wrote:
>> Every processor I've ever used (I think) had an 'or' instruction. But
>> you're right, checking a few kB of recent dsPIC assembler I wrote, I've
>> used 'or' once, 'and' quite a bit and 'xor' a few times.
> How about not having the AND instruction? The TMS9900 which is still
> popular with some FPGA CPU fans has an OR instruction, SOC/SOCB (set
> ones corresponding) but the matching pair is SZC/SZCB (set zeros
> corresponding) which inverts the mask before anding. There is an
> immediate mode and instruction though, ANDI.

I chose NAND as the essential logical primitive for my Forth. It makes
it easy to synthesize AND, OR, XOR, and INVERT.

Well, XOR is perhaps not easy; still not that bad:

: xor 2dup nand 1+ dup + + + ;

[Cecil Bayona]

An example in my life was writing complex software in C, it became a
major problem in C finding bugs that crashed the system. I was going
insane trying to find the bugs, there was a lot of pressure as the
client was using the software and demanded stability. I bit the bullet
and wrote a program to translate the C code into Borland Pascal, after a
weekend of getting the translator to work right I had a working version
of the software in Borland Pascal, I then turned on all the safety
features in the Borland compiler on and re-compiled the code, within
less than an hour the Borland run code started complaining about
problems, mostly uninitialized pointers, after fixing them the customer
mentioned that in over a week the system had not crashed or glitched
once, this was a big life lesson.

After that experience I stopped using C for projects, Borland Pascal's
compile and run-time checks would catch all sorts of dumb mistakes that
I would have missed using C. It didn't take long to get used to Pascals
wordier way of writing code, and the requirement of explicit casting, in
the end I could write code in my sleep in Borland Pascal and did not get
nasty surprises, it was worth the effort.

The moral learned was pay now pay later, later bring interest payments
with it so it's far better to pay now. This indecision between Verilog
and VHDL seems a lot similar to my issues between C and Borland Pascal
so maybe that experience applies here too.

When I first wanted to start this software project I dug out my old
copies of Borland Pascal but the problem is that they would not install
or run with Windows 10 so that reliable and efficient software was out
of the picture since a new copy is out of reach due to it's cost of over
$1400 for the professional version, that is why I started looking at Go,
efficient yet full of checks to keep you out of trouble.
--
Cecil - k5nwa

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 21:15:46 UTC+3 пользователь rickman написал:

> On 4/25/2017 1:37 PM, Cecil Bayona wrote:
> >
> > I have books on both languages so I will think about it for a month or
> > two before I have to make a decision.
>
> Oh yeah, if you do decide to use VHDL I don't ever want to see you use
>
> if (clk'event and clk '1')
>

if rising_edge(clk)

[hughag...@gmail.com]

Rickman has threatened to burn your house down --- aren't you scared? --- good thing you are in Russia, rather than in Rickman's city which is presumably here in the "Land of the Free."

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 21:20:02 UTC+3 пользователь Cecil - k5nwa написал:

Lazarus IDE based on Free Pascal looks like Delphi and follow that way. If you need only basic visual controls, it is ebough. Also you can add some Forth scripts to buttons, checkboxes etc.

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 21:38:05 UTC+3 пользователь hughag...@gmail.com написал:

Checking my abilities to defend myself, it is better to Rickman to not to try make me scared :D

[rickman]

On 4/25/2017 2:19 PM, Cecil Bayona wrote:
>
> An example in my life was writing complex software in C, it became a
> major problem in C finding bugs that crashed the system. I was going
> insane trying to find the bugs, there was a lot of pressure as the
> client was using the software and demanded stability. I bit the bullet
> and wrote a program to translate the C code into Borland Pascal, after a
> weekend of getting the translator to work right I had a working version
> of the software in Borland Pascal, I then turned on all the safety
> features in the Borland compiler on and re-compiled the code, within
> less than an hour the Borland run code started complaining about
> problems, mostly uninitialized pointers, after fixing them the customer
> mentioned that in over a week the system had not crashed or glitched
> once, this was a big life lesson.

What was the underlying cause of these problems? It wasn't the C
compiler.

> After that experience I stopped using C for projects, Borland Pascal's
> compile and run-time checks would catch all sorts of dumb mistakes that
> I would have missed using C. It didn't take long to get used to Pascals
> wordier way of writing code, and the requirement of explicit casting, in
> the end I could write code in my sleep in Borland Pascal and did not get
> nasty surprises, it was worth the effort.

Did you consider the idea of not writing bad code in the first place?
That's where you are with Forth. It has very little in the way of
compiler checks. You have to avoid mistakes by not writing them.

Personally I find it interesting that I use VHDL and Forth. I don't
think you can find two more opposite languages in terms of error checking.

> The moral learned was pay now pay later, later bring interest payments
> with it so it's far better to pay now. This indecision between Verilog
> and VHDL seems a lot similar to my issues between C and Borland Pascal
> so maybe that experience applies here too.

I have made a lot of money by paying later. I bought two houses on
mortgages and both are paid off now with values higher than the cost of
the loans. By paying cash I would barely be buying the first one now,
if that!

> When I first wanted to start this software project I dug out my old
> copies of Borland Pascal but the problem is that they would not install
> or run with Windows 10 so that reliable and efficient software was out
> of the picture since a new copy is out of reach due to it's cost of over
> $1400 for the professional version, that is why I started looking at Go,
> efficient yet full of checks to keep you out of trouble.

Oh, so you don't use Forth much then? Is that just a hobby thing with you?

I just don't end up adding bugs to my code so much. With Forth the
small unit testing works very well. With VHDL I spend a lot of time
thinking about how the code will work together, then simulation finds
the bugs much more easily than running in the chip.

I seriously think it was an epiphany for me when Jeff Fox wrote that
stack errors just mean the programmer can't count. Avoiding stack
errors is literally that simple, count the parameters added and removed
from the stack. A compiler isn't needed to find those errors, just as,
in my opinion, a compiler isn't needed to find uninitialized pointers.
Heck, we had to perform requirements traceability analysis which was all
done by hand. Why can't uninitialized pointers be found as you code?

--

Rick C

[Cecil Bayona]

On 4/25/2017 1:11 PM, rickman wrote:
> On 4/25/2017 1:37 PM, Cecil Bayona wrote:

>
> But if you know these are mistakes, can't you avoid them on your own?
>
> I have used VHDL for so long that I don't even have to think about
> avoiding all the compiler complaints, it is pretty automatic. If I knew
> the issues to avoid in Verilog I don't think I would have too much
> trouble with it.
>
>

That is what I think about sometimes, even in C one can be careful and
avoid the dumb mistakes but one has to be paying attention to the subtle
issues.

>> Human nature can often work out against a persons best interest. Take
>> the quicker route but pay for the rest of your life. Too many persons
>> with vast experience on FPGAs keep coming up with the same advice it
>> would most likely be prudent to listen to it and learn the more
>> difficult approach up front rather than pay for the simpler way many
>> times over.
>
> I've never met anyone using Verilog that thought it was a mistake. Where
> is Bernd Paysan to weigh in?
>
>
>> I have books on both languages so I will think about it for a month or
>> two before I have to make a decision.
>
> I have one book in *both* languages, "HDL Chip Design" by Douglas J
> Smith. It is not organized like a typical text book starting you at the
> basics of HDL. It does however, show each example in VHDL and Verilog
> side by side. Unless it has been updated for VHDL-2008 it shows
> VHDL-1993 as my copy does. I strongly encourage anyone interested in
> VHDL to learn VHDL-2008. If you don't, there is little point to using
> VHDL, that's how significant the improvements are.
>

I have that book not useful for learning the language from scratch but
useful for the examples on how to do things.

--
Cecil - k5nwa

[Jan Coombs]

The MyHDL python HDL simulator [1] is as fast as any other free
simulator [2], and exports Verilog and VHDL for synthesis.

Jan Coombs
--
[1] http://myhdl.org/
[2] http://myhdl.org/docs/performance.html
(I have sample source for b16, j1)

[Cecil Bayona]

On 4/25/2017 1:38 PM, Ilya Tarasov wrote:
> вторник, 25 апреля 2017 г., 21:20:02 UTC+3 пользователь Cecil - k5nwa написал:

>> The moral learned was pay now pay later, later bring interest payments
>> with it so it's far better to pay now. This indecision between Verilog
>> and VHDL seems a lot similar to my issues between C and Borland Pascal
>> so maybe that experience applies here too.
>>
>> When I first wanted to start this software project I dug out my old
>> copies of Borland Pascal but the problem is that they would not install
>> or run with Windows 10 so that reliable and efficient software was out
>> of the picture since a new copy is out of reach due to it's cost of over
>> $1400 for the professional version, that is why I started looking at Go,
>> efficient yet full of checks to keep you out of trouble.
>> --
>
> Lazarus IDE based on Free Pascal looks like Delphi and follow that way. If you need only basic visual controls, it is ebough. Also you can add some Forth scripts to buttons, checkboxes etc.
>

I thought about it, but I have never used it before so I have questions
about how reliable it is and if it generates accurate code, it has a
following so it must be OK in those areas. Even if it's not the best
optimized compiler is must be accurate to intent or there is no point.

I visited the Embarcadero site and now they offer a free version od
Delphi like Borland used to do, with Borland it was a pretty good system
for free, it was missing the Database items but otherwise it was pretty
good, I always bought the Professional version with Database capability.
I'm installing it now so I will shortly find out how good it is.

In any case I'm determined to learn Go for some system applications I
want that need MySQL capability. For Visual Design Borland Delphi was
wonderful.


--
Cecil - k5nwa

[Cecil Bayona]

A Kalashnikov is a wonderful equalizer, it can solve difficult problems
quite effectively.

--
Cecil - k5nwa

[rickman]

I'm not getting how this works. When you dup and add the result of the
NAND 1+ it propagates a carry between bits. Seems to me that will mess
up any bitwise logic operation.

--

Rick C

[rickman]

On 4/25/2017 2:51 PM, Cecil Bayona wrote:
> On 4/25/2017 1:11 PM, rickman wrote:
>> On 4/25/2017 1:37 PM, Cecil Bayona wrote:
>
>>
>> But if you know these are mistakes, can't you avoid them on your own?
>>
>> I have used VHDL for so long that I don't even have to think about
>> avoiding all the compiler complaints, it is pretty automatic. If I
>> knew the issues to avoid in Verilog I don't think I would have too
>> much trouble with it.
>>
>>
>
> That is what I think about sometimes, even in C one can be careful and
> avoid the dumb mistakes but one has to be paying attention to the subtle
> issues.

I think that is where we differ. I don't think the issues are subtle.
They are pretty obvious in my experience, at least once you learn what
they are. That's why I don't want to use Verilog without a Verilog book
that points them out. I don't want to design in bugs and have them get
through testing only to be found in the field.

>>> Human nature can often work out against a persons best interest. Take
>>> the quicker route but pay for the rest of your life. Too many persons
>>> with vast experience on FPGAs keep coming up with the same advice it
>>> would most likely be prudent to listen to it and learn the more
>>> difficult approach up front rather than pay for the simpler way many
>>> times over.
>>
>> I've never met anyone using Verilog that thought it was a mistake.
>> Where is Bernd Paysan to weigh in?
>>
>>
>>> I have books on both languages so I will think about it for a month or
>>> two before I have to make a decision.
>>
>> I have one book in *both* languages, "HDL Chip Design" by Douglas J
>> Smith. It is not organized like a typical text book starting you at
>> the basics of HDL. It does however, show each example in VHDL and
>> Verilog side by side. Unless it has been updated for VHDL-2008 it
>> shows VHDL-1993 as my copy does. I strongly encourage anyone
>> interested in VHDL to learn VHDL-2008. If you don't, there is little
>> point to using VHDL, that's how significant the improvements are.
>>
>
> I have that book not useful for learning the language from scratch but
> useful for the examples on how to do things.

Both languages are pretty easy to learn actually. The only hard part is
letting go of the ideas you have entrenched from writing software. HDL
stands for Hardware Description Language which is how you need to treat
it unless you have gobs of space in the part and don't care about the
speed of your design. I design thinking of the hardware produced rather
than the way I think of software which is more abstract and about the
data structures and operations on them.

When you describe a given behavior the tool will give you a design that
implements *exactly* that behavior, no more, no less.

--

Rick C

[rickman]

It doesn't work very well against web based attacks.

--

Rick C

[hughag...@gmail.com]

I can really do without Rickman and his threats --- he has been on my twit list for quite some time --- I don't have anything to do with him.

I don't really know enough about HDL to have an opinion on the endless VHDL-vs-Verilog debate. The vibe I'm picking up though, is that Ilya knows a lot about the subject, and that Rickman is is full of beans --- certainly Rickman knows nothing about Forth software, which is a subject that I do have an opinion on --- this is not to say that I agree with everything Ilya says in regard to Forth software, although I do consider his opinion to be worthy of discussion.

[Cecil Bayona]

On 4/25/2017 1:49 PM, rickman wrote:
> On 4/25/2017 2:19 PM, Cecil Bayona wrote:
>>
>> An example in my life was writing complex software in C, it became a
>> major problem in C finding bugs that crashed the system. I was going
>> insane trying to find the bugs, there was a lot of pressure as the
>> client was using the software and demanded stability. I bit the bullet
>> and wrote a program to translate the C code into Borland Pascal, after a
>> weekend of getting the translator to work right I had a working version
>> of the software in Borland Pascal, I then turned on all the safety
>> features in the Borland compiler on and re-compiled the code, within
>> less than an hour the Borland run code started complaining about
>> problems, mostly uninitialized pointers, after fixing them the customer
>> mentioned that in over a week the system had not crashed or glitched
>> once, this was a big life lesson.
>
> What was the underlying cause of these problems? It wasn't the C compiler.

Not the compiler but the language is like the Wild West anything goes so
if one is not careful you can have mistakes that are difficult to find.
Pascal and Go are languages that are restricted and check for dumb issues.

>
>
>> After that experience I stopped using C for projects, Borland Pascal's
>> compile and run-time checks would catch all sorts of dumb mistakes that
>> I would have missed using C. It didn't take long to get used to Pascals
>> wordier way of writing code, and the requirement of explicit casting, in
>> the end I could write code in my sleep in Borland Pascal and did not get
>> nasty surprises, it was worth the effort.
>
> Did you consider the idea of not writing bad code in the first place?
> That's where you are with Forth. It has very little in the way of
> compiler checks. You have to avoid mistakes by not writing them.
>
> Personally I find it interesting that I use VHDL and Forth. I don't
> think you can find two more opposite languages in terms of error checking.

Ah now you are getting to the root cause, writing bad code is too easy,
and if you are in a hurry you can miss things that will burn you later.

But like you I like Forth which has no checks for anything so what is
the difference?

C is usually written top down with a lot of code being written before
one can test anything, this leads to more bugs, one is building on a
foundation of untested code.

Forth also is like the Wild West but one writes code in a totally
different way. One writes Forth mostly bottom up, writing small
routines that are easily tested before using them elsewhere, the result
is relatively error free code. C on the hand with its lengthy edit,
compile, then test way of doing things encourages one to add a lot of
untested code to a program which then tends to have more bugs.

One of the reasons for looking at Go is it's lightning fast compiler
which makes it more similar to Forth than to C but still Forth is
wonderful for testing software as you go by it interactive nature and
it's culture of writing small procedures that are easily tested, that is
possible because the low overhead in calling small procedures.

So they could be opposite but the both can work out well.

>
>
>> The moral learned was pay now pay later, later bring interest payments
>> with it so it's far better to pay now. This indecision between Verilog
>> and VHDL seems a lot similar to my issues between C and Borland Pascal
>> so maybe that experience applies here too.
>
> I have made a lot of money by paying later. I bought two houses on
> mortgages and both are paid off now with values higher than the cost of
> the loans. By paying cash I would barely be buying the first one now,
> if that!

Not applicable here.

>
>
>> When I first wanted to start this software project I dug out my old
>> copies of Borland Pascal but the problem is that they would not install
>> or run with Windows 10 so that reliable and efficient software was out
>> of the picture since a new copy is out of reach due to it's cost of over
>> $1400 for the professional version, that is why I started looking at Go,
>> efficient yet full of checks to keep you out of trouble.
>
> Oh, so you don't use Forth much then? Is that just a hobby thing with you?
>

For a long time large applications were written in Delphi, smaller tools
were written in Forth, that worked out well as large applications needed
a lot of libraries not available in Forth. Small tools specially if they
interfaced to hardware were a lot easier to write and debug in Forth so
it was a tool to be used when the purpose suited it, when it does then
it's a wonderful language where one can write error free code like no other.

Actually Forth can be good for large applications but one needs
libraries to accomplish some complicated task, according to people here
it's to be avoided. For Delphi I wrote some B Tree Database routines
that were incredibly fast but it took a while to debug them and the code
was fairly large some here insist that it be written for each
application, that is insane so for large applications I had all sorts of
libraries in Delphi that were tested and made my life much easier.

> I just don't end up adding bugs to my code so much. With Forth the
> small unit testing works very well. With VHDL I spend a lot of time
> thinking about how the code will work together, then simulation finds
> the bugs much more easily than running in the chip.
>
> I seriously think it was an epiphany for me when Jeff Fox wrote that
> stack errors just mean the programmer can't count. Avoiding stack
> errors is literally that simple, count the parameters added and removed
> from the stack. A compiler isn't needed to find those errors, just as,
> in my opinion, a compiler isn't needed to find uninitialized pointers.
> Heck, we had to perform requirements traceability analysis which was all
> done by hand. Why can't uninitialized pointers be found as you code?
>

In C one can write a lot of code before anything is tested and somewhere
along the line a pointer might not have been initialized, it's easy to
miss sometimes.

With Forth that is not much of an issue all routines are small so you
can see what you are doing.
--
Cecil - k5nwa

[Cecil Bayona]

But I found documentation on it to practically not exist so when I
looked at it I was lost. Sounds good in principle, Python is a very
simple language.

--
Cecil - k5nwa

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 21:59:13 UTC+3 пользователь Cecil - k5nwa написал:

I use Lazarus for internal tools, IDE with Forth as dll works fine. In this case we don't need an ultimate performance. Bad thing is too large exe size, but no additional libraries needed. Indeed, after Embarcadero stops providing free version of Delphi it lost a large part of popularity. Qt Creator or Visual Studio are not so bad.

[Lars Brinkhoff]

rickman wrote:
>> : xor 2dup nand 1+ dup + + + ;
>
> I'm not getting how this works. When you dup and add the result of
> the NAND 1+ it propagates a carry between bits. Seems to me that will
> mess up any bitwise logic operation.

Thanks for asking! I used a trick. You can define addition in terms of
XOR, AND, and shift, so I used this to define XOR in terms of AND,
shift, and addition. Plus probably a few more tricks I don't remember
now.

I had a preference for using + since that's another of my essential
primitives.

[Cecil Bayona]

On 4/25/2017 1:54 PM, Jan Coombs wrote:

I will look at it again but when I looked at it sometime back there was
no explanation on how it worked maybe it's better now. I have a month or
two before I need to get back to this so I will evaluate it again.

In the meantime I would not mind a copy of the J1 implementation so I
can compare VHDL, Verilog and MyVHL and see the difference. Is it
available somewhere?



--
Cecil - k5nwa

[Ilya Tarasov]

вторник, 25 апреля 2017 г., 22:00:52 UTC+3 пользователь Cecil - k5nwa написал:

Of course! I still remember Soviet school with lessons how to disassemble AK-74. After getting 50 out of 50 in shooting gallery I almost lost interest to that things. Jian sword is pretty well weapon too. :))

[hughag...@gmail.com]

At the risk of sounding like a total American chauvinist, let me note that American carbines are of far higher quality than Russian carbines.

During WWII, there were two competing designs for rifles for the Russian army --- one design provided good accuracy but was expensive to manufacture, and the other design provided poor accuracy but was inexpensive to manufacture. Stalin famously said: "Quantity has a quality of its own." He wanted to get as many rifles in the field as possible, without regard to accuracy --- he wanted a line of soldiers to fire on the enemy continuously and hopefully hit something by luck, or at least scare the pee out of them. Similarly, the katyusha provides quantity rather than quality --- ironically, the Chechen's used the katyusha quite effectively against the Soviets --- this works well against an opponent who wants to fight a static war with a well-defined front-line.

Similarly, when I play Go, if my situation is bad, I try to create complication to confuse my opponent and awe the spectators. This works quite well half of the time (the other half of the time I confuse myself and amuse the spectators).

Nowadays, the AK-47 is primarily used in Africa. The reason is that most of the soldiers are malnourished, and eyesight is the first thing that is affected by malnourishment --- they can't see beyond 100 yards --- they wouldn't be able to make use of a carbine that is accurate to 100 yards, but there are a lot of them, so: "Quantity has a quality of its own."

[rickman]

On 4/25/2017 3:27 PM, hughag...@gmail.com wrote:
>
> I can really do without Rickman and his threats --- he has been on my twit list for quite some time --- I don't have anything to do with him.

That is the highest praise anyone can receive from Hugh. I feel honored.

> I don't really know enough about HDL to have an opinion

Good that you recognize that. Too bad you can't recognize some of the
poor thought processes you seem to praise in others. Figuring out which
tool is better to learn is a personal decision, which should be clear
just from the fact that so many continue to pick different tools even
after years of consideration.

There is no "right" choice in Verilog vs. VHDL (unless you are Bernd
Paysan). Each of us have our own styles and preferences.

--

Rick C

[hughag...@gmail.com]

On Saturday, April 22, 2017 at 12:50:57 PM UTC-7, Cecil - k5nwa wrote:
> On 4/22/2017 1:48 PM, Clive Arthur wrote:
> > On 21/04/2017 23:55, rickman wrote:
> >> On 4/21/2017 3:49 AM, JUERGEN wrote:
> >>> see https://www.amazon.com/dp/B071D3XMPS and
> >>> https://wiki.forth-ev.de/doku.php/projects:ep32:start The core is
> >>> running eForth on my desk in a low cost Lattice DevBoard and there has
> >>> been an ASIC implementation in the past already as google told me
> >>
> >> Does this processor have any particular purpose or advantage over other
> >> stack processors?
> >>
> > It seems it's small, but with a limited instruction set, so some simple
> > Forth words may take several clock cycles. For example, OR is made with
> > com pushr com popr and com, which I guess would be
> >
> > : or
> > not >r not r> and not
> > ;
> >
> > Looks a bit tedious, but maybe if you're pushed for space and speed
> > isn't everything...
> >
> > Cheers
> The designer chose to use 5 bits for the instructions but he made
> provisions for 6 bits but of course changes are needed to be made to
> implement that, it would allow for 64 primitives instead of 32. Still
> the most often used words are primitives that execute in one clock, the
> "or" happens to be one of instructions left out because the limit with 5
> bits.
>
> I intend to make the instruction word 6 bits and add extra primitives,
> there is plenty of space in the FPGA left, All the available RAM is not
> being used either and that is another change I intend to make when I
> finish my current software project.

This idea was considered when the MiniForth project started at Testra. We would have a 5-bit instruction field and have 32 primitives. I spent a few days figuring out which 32 primitives we would have --- there are a lot of trade-offs because what we typically think of as being primitives can be defined in terms of each other --- so the question is which get defined in hardware and which get defined in software at a huge cost in performance.

This bad idea was quickly dropped. Instead we went with a design in which the processor has a Harvard Architecture and there is a low-level machine-code that the primitives are written in. This was a much better idea. I wrote hundreds of primitives --- some I wrote by hand and some were generated by meta-compiling words (so I would have a lot of primitives that had only slight differences).

I consider this system, with the low-level machine-language and the unlimited number of primitives, to be a much better design than the limited system with 32 primitives (or 64 primitives nowadays). Ilya says that he has done something similar, although I haven't seen it.

OTOH, my Stundurd processor design was a limited system with a finite number of primitives. I don't know enough about HDL to say if it is a good design. I was assuming that it is difficult to have conditional execution within the primitives --- that was true in 1994 --- may not be true nowadays.

[Cecil Bayona]

Ah, but I wasn't saying it was the best rifle/carbine probably it's
quite capable on handling close up problems, even the Russians did not
used it as a sniper rifle but instead use varios rifles mostly bolt
action for sniper duty. The M1 Garand is probably what you are referring
to, reliable and quite accurate.

In bolt action rifles of WWII then the Mouser 98 was a great rifle and
action, but often overlooked is the British Lee Enfield 4 which had many
advance features.

--
Cecil - k5nwa

[rickman]

On 4/25/2017 3:29 PM, Cecil Bayona wrote:
> On 4/25/2017 1:49 PM, rickman wrote:
>> On 4/25/2017 2:19 PM, Cecil Bayona wrote:
>>>
>>> An example in my life was writing complex software in C, it became a
>>> major problem in C finding bugs that crashed the system. I was going
>>> insane trying to find the bugs, there was a lot of pressure as the
>>> client was using the software and demanded stability. I bit the bullet
>>> and wrote a program to translate the C code into Borland Pascal, after a
>>> weekend of getting the translator to work right I had a working version
>>> of the software in Borland Pascal, I then turned on all the safety
>>> features in the Borland compiler on and re-compiled the code, within
>>> less than an hour the Borland run code started complaining about
>>> problems, mostly uninitialized pointers, after fixing them the customer
>>> mentioned that in over a week the system had not crashed or glitched
>>> once, this was a big life lesson.
>>
>> What was the underlying cause of these problems? It wasn't the C
>> compiler.
>
> Not the compiler but the language is like the Wild West anything goes so
> if one is not careful you can have mistakes that are difficult to find.
> Pascal and Go are languages that are restricted and check for dumb issues.

The problem isn't the tool. I may not be the world's best expert in
anything, but one thing I have learned is that mistakes are made by
people and only people can prevent them.

One of the most rigorous processes for avoiding mistakes is that used to
design and build nuclear reactors and yet nuclear reactors have problems
and even accidents.

I'm not suggesting that we should build nuclear reactors without
processes to minimize mistakes. I'm saying that for software
development you can do a very decent job by using the sorts of methods
we use in programming in Forth which is to simplify the problems in ways
that make the mistakes easier to avoid.

You said it yourself, "if one is not careful you can have mistakes"...
So program with intent and test early and often.

I guess I have very seldom seen a compiler prevent me from making a
mistake that was, "difficult to find". Those mistakes require a human. ;)

>>> After that experience I stopped using C for projects, Borland Pascal's
>>> compile and run-time checks would catch all sorts of dumb mistakes that
>>> I would have missed using C. It didn't take long to get used to Pascals
>>> wordier way of writing code, and the requirement of explicit casting, in
>>> the end I could write code in my sleep in Borland Pascal and did not get
>>> nasty surprises, it was worth the effort.
>>
>> Did you consider the idea of not writing bad code in the first place?
>> That's where you are with Forth. It has very little in the way of
>> compiler checks. You have to avoid mistakes by not writing them.
>>
>> Personally I find it interesting that I use VHDL and Forth. I don't
>> think you can find two more opposite languages in terms of error
>> checking.
>
> Ah now you are getting to the root cause, writing bad code is too easy,
> and if you are in a hurry you can miss things that will burn you later.

Huh? Not sure what I said about that. But don't be in a hurry. It has
been documented many, many times that spending time up front on analysis
and proper design methods will get you to a finished product faster than
rushing. The hurrier I go, the behinder I get.

> But like you I like Forth which has no checks for anything so what is
> the difference?

The difference is a huge amount of work you spend in VHDL coding and the
huge amount of work you spend in Forth with low level testing. I would
prefer that testing were easier in VHDL. The issue is not so much the
effort required to design a test bench. For me it is the tools which
require you to set up a project and designate folders and all manner of
initialization to begin a simulation. The tool providers seem to be
very focused on the "BIG" picture and not the little ones, so the little
efforts are hard.

> C is usually written top down with a lot of code being written before
> one can test anything, this leads to more bugs, one is building on a
> foundation of untested code.

Nonesense. Forth is often written top down with testing by using stubs.
Or C can be *designed* top down and written/tested bottom up.

> Forth also is like the Wild West but one writes code in a totally
> different way. One writes Forth mostly bottom up, writing small
> routines that are easily tested before using them elsewhere, the result
> is relatively error free code. C on the hand with its lengthy edit,
> compile, then test way of doing things encourages one to add a lot of
> untested code to a program which then tends to have more bugs.

Don't confuse writing code with design. Sounds to me like you aren't
used to performing design separate from coding.

> One of the reasons for looking at Go is it's lightning fast compiler
> which makes it more similar to Forth than to C but still Forth is
> wonderful for testing software as you go by it interactive nature and
> it's culture of writing small procedures that are easily tested, that is
> possible because the low overhead in calling small procedures.
>
> So they could be opposite but the both can work out well.
>
>>
>>
>>> The moral learned was pay now pay later, later bring interest payments
>>> with it so it's far better to pay now. This indecision between Verilog
>>> and VHDL seems a lot similar to my issues between C and Borland Pascal
>>> so maybe that experience applies here too.
>>
>> I have made a lot of money by paying later. I bought two houses on
>> mortgages and both are paid off now with values higher than the cost
>> of the loans. By paying cash I would barely be buying the first one
>> now, if that!
>
> Not applicable here.

It was your analogy... ;)

>>> When I first wanted to start this software project I dug out my old
>>> copies of Borland Pascal but the problem is that they would not install
>>> or run with Windows 10 so that reliable and efficient software was out
>>> of the picture since a new copy is out of reach due to it's cost of over
>>> $1400 for the professional version, that is why I started looking at Go,
>>> efficient yet full of checks to keep you out of trouble.
>>
>> Oh, so you don't use Forth much then? Is that just a hobby thing with
>> you?
>>
>
> For a long time large applications were written in Delphi, smaller tools
> were written in Forth, that worked out well as large applications needed
> a lot of libraries not available in Forth. Small tools specially if they
> interfaced to hardware were a lot easier to write and debug in Forth so
> it was a tool to be used when the purpose suited it, when it does then
> it's a wonderful language where one can write error free code like no
> other.
>
> Actually Forth can be good for large applications but one needs
> libraries to accomplish some complicated task, according to people here
> it's to be avoided.

What's to be avoided??? Using libraries or accomplishign complicated
tasks?

> For Delphi I wrote some B Tree Database routines
> that were incredibly fast but it took a while to debug them and the code
> was fairly large some here insist that it be written for each
> application, that is insane so for large applications I had all sorts of
> libraries in Delphi that were tested and made my life much easier.
>
>> I just don't end up adding bugs to my code so much. With Forth the
>> small unit testing works very well. With VHDL I spend a lot of time
>> thinking about how the code will work together, then simulation finds
>> the bugs much more easily than running in the chip.
>>
>> I seriously think it was an epiphany for me when Jeff Fox wrote that
>> stack errors just mean the programmer can't count. Avoiding stack
>> errors is literally that simple, count the parameters added and
>> removed from the stack. A compiler isn't needed to find those errors,
>> just as, in my opinion, a compiler isn't needed to find uninitialized
>> pointers. Heck, we had to perform requirements traceability analysis
>> which was all done by hand. Why can't uninitialized pointers be found
>> as you code?
>>
>
> In C one can write a lot of code before anything is tested and somewhere
> along the line a pointer might not have been initialized, it's easy to
> miss sometimes.

That is not at all related to the language. You can do stupid things in
any language.

> With Forth that is not much of an issue all routines are small so you
> can see what you are doing.

They are only small if you write them small. In VHDL I try to keep my
modules small although that has a different meaning than in Forth. I
want to try coding the bulk of my work in procedures sometime. I know
people who do that, but I don't see how what they are doing is very
useful. One in particular would separate the three sections of a
sequential process. One was initialization but I can't think what the
other two were. Anyway, he would code the three sections as procedures
which sounds nice from a Forth perspective, but there is no way to test
a procedure in VHDL without the supporting code. He thought it provided
more organized code, but I didn't see the difference since the three
sections are all very apparent when coded inline. They are all dealing
with the same signals and variables, so I just didn't see the advantage
in splitting them up.

So while I think most aspects of design, coding and testing we have
talked about are language agnostic, Forth does lend itself to smaller
module sizes.

--

Rick C

[hughag...@gmail.com]

On Tuesday, April 25, 2017 at 1:04:08 PM UTC-7, rickman wrote:
> On 4/25/2017 3:27 PM, hughag...@gmail.com wrote:
> >
> > I can really do without Rickman and his threats --- he has been on my twit list for quite some time --- I don't have anything to do with him.
>
> That is the highest praise anyone can receive from Hugh. I feel honored.

And yet, you don't leave me alone...

You said this previously (talking about me, afaik):
"He doesn't bother me so much as others. But I realize I have been
feeding him again. It's just that he's so *cute* when you give him a
cookie and he does the little dance."

No matter what I do, you always contradict it and explain that I'm stupid to have said do. All the ANS-Forth trolls are like this. If I use a self-balancing binary-tree (as I did in ASSOCIATION.4TH) then everybody says that a hash-table is better and that I'm stupid to have used a self-balancing binary-tree. Better for what? This criticism would only make sense if I were working for them and programming to their specifications, but I'm not (or, if I am, the paychecks seem to have gotten lost in the mail). I have no doubt that if I implemented a hash-table the ANS-Forth trolls would say that a self-balancing binary-tree is better and that I'm stupid to have used a hash-table.

These internet forums are cheap entertainment for twits --- they just contradict everybody with idiotic arguments, or they call people "insane," hoping to get a response --- they give the programmer a cookie to induce him to do a little dance for their entertainment.

I'm not a troll though --- I write ANS-Forth code that works --- I'm pretty much the only person on this forum who does this.

Elizabeth Rather is a twit magnet. She only cares about loyalty, so she attracts twits to herself --- they tell her that she is the "leading expert" of Forth --- in exchange, she gives them a haven where they can play their troll games without any criticism for their loathsome behavior from the committee (Anton Ertl, Stephen Pelc, Peter Knaggs, Leon Wagner, Andrew Haley, etc.).

[rickman]

On 4/25/2017 4:10 PM, hughag...@gmail.com wrote:
>
> OTOH, my Stundurd processor design was a limited system with a finite
> number of primitives. I don't know enough about HDL to say if it is a
> good design. I was assuming that it is difficult to have conditional
> execution within the primitives --- that was true in 1994 --- may not
> be true nowadays.

I have no idea why you say conditional execution within a primitive
(instruction) would be difficult. If you mean that literally (the
instruction is executed conditionally) that is *very* easy and would
have been easy at literally any time in computer development other than
perhaps in relay circuits (and maybe even then). Registers in a CPU
enabled, that's how a CPU works, writing to some registers on some
instructions and others in other instructions. But usually the enables
are simple opcode decodes. For conditional jumps a mux selects the
source of the address for the next instruction fetch rather than
enabling a register since the next instruction address is typically
incremented. But when it is another register that is enabled, the top
of stack in an operation that is negating it for example, the register
enable can be gated by whatever the condition code is.

--

Rick C

[Cecil Bayona]

One cannot write every detail of the software writing process in a email
or news post, if I did I would have a book, picking at little details
because it was not mentioned does not mean I'm not aware of them.
Remember that, it makes for a more pleasant conversation.

I have mentioned it here before when I write software I even have a
notebook with all the software requirements, all the details of the
software methodology including flowcharts and UML charts, I use State
Diagrams when needed to document program/data triggers, and the source
is well documented so I do plan the software well, but we are humans and
we can make mistakes with the best of intentions.

Some languages are more prone than others to allow mistakes to slip by,
C is well known for that. I always write my Forth applications bottom up
because Forth allows me to, I prefer writing software bottom up when
it's practical because it eliminates a lot of low level mistakes and
actually works quite well doing so.

--
Cecil - k5nwa

[hughag...@gmail.com]

On Tuesday, April 25, 2017 at 12:29:26 PM UTC-7, Cecil - k5nwa wrote:
> In C one can write a lot of code before anything is tested and somewhere
> along the line a pointer might not have been initialized, it's easy to
> miss sometimes.

One can do that in Forth too. In Forth however, the culture says that good style is bottom-up rather than top-down, and the interactive command-line makes testing of small functions easy so good style is encouraged --- in C good style is not rewarded (because you are going to debug using a single-step debugger), and hence bad style (top-down programming with huge functions) is the culture.

> With Forth that is not much of an issue all routines are small so you
> can see what you are doing.

I recommend defensive programming. For example, we had this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/LcuvmV8k7A0

On Sunday, April 23, 2017 at 1:41:27 PM UTC-7, hughag...@gmail.com wrote:
> On Friday, April 21, 2017 at 7:11:44 PM UTC-7, Elizabeth D. Rather wrote:
> > Here you go:
> > : CVARIABLE ( -- ) CREATE 1 ALLOT
> > DOES> ( - a ) ;
>
> You are so bad at Forth programming that you screwed up even this super-trivial Forth code!
>
> Here you go:
>
> : cvariable create 0 c, ;
>
> The 0 C, is necessary so the program does the same thing every time if the programmer forgets to store a value in the variable before fetching from it (a common bug). With your code, you are initializing the variable to whatever happened to be in memory. The program may work after some compiles, and may not work after other compiles --- this is difficult bug to track down.
>
> Note that this is the same design flaw that Anton Ertl made in his definition of {: --- he had the locals after the | being initialized to an unknown value --- the correct way to do this (what I did in the novice-package) is initialize them to zero.

It is a good idea to anticipate bugs --- for example, a common bug is to use a variable without first initializing it --- so you write your code in such a way that if this bug occurs it will get caught.

Another common bug is to call a function with illegal parameters --- this can be checked, so you get an abort with a helpful error message, rather than bizarre behavior that baffles the programmer as to where the bug is --- anybody writing a code-library should put checks like this in to help the users of that code-library.

My experience with MFX is that most of the bugs were the result of getting my vocabulary usage screwed up. These bugs resulted in some truly bizarre behavior of the software that gave me no clue at all as to where the bug was and baffled me for days. The big breakthrough with that program was to write code (this was UR/Forth specific) that could determine from an xt what vocabulary it was in --- I then wrote checks to make sure before executing the xt that it was in the correct vocabulary --- when I did this, I was able to find bugs within minutes that had previously taken me days to find, and pretty soon there were no bugs anymore. :-D

[rickman]

On 4/25/2017 4:36 PM, hughag...@gmail.com wrote:
> On Tuesday, April 25, 2017 at 1:04:08 PM UTC-7, rickman wrote:
>> On 4/25/2017 3:27 PM, hughag...@gmail.com wrote:
>>>
>>> I can really do without Rickman and his threats --- he has been
>>> on my twit list for quite some time --- I don't have anything to
>>> do with him.
>>
>> That is the highest praise anyone can receive from Hugh. I feel
>> honored.
>
> And yet, you don't leave me alone...

LOL!!! This is the Internet where you don't have to read a single word
I write!!! Just ignore me. Killfile me. When you see my name on a
post delete it without opening!!!

You are just too funny sometimes.

> You said this previously (talking about me, afaik): "He doesn't
> bother me so much as others. But I realize I have been feeding him
> again. It's just that he's so *cute* when you give him a cookie and
> he does the little dance."

Yeah, we should both ignore each other, but sometimes what you say is so
wrong and it's hard to let people be wrong on the Internet.

> No matter what I do, you always contradict it and explain that I'm
> stupid to have said do.

I may have used the S word at some point, but I don't think so.
Certainly I have said I think you know a lot about Forth. I just think
you have a number of prejudices that make your thinking a bit erratic
and sometimes your psychotic tendencies make it very hard for anyone to
talk to you. My GOD! you can go on rants that mimic the Unibomber.

> All the ANS-Forth trolls are like this. If I
> use a self-balancing binary-tree

<<...ranting snipped...> >

> I'm not a troll though --- I write ANS-Forth code that works

Writing code doesn't preclude you from being a troll. I think you much
prefer to talk about things other than Forth or you wouldn't do it so much.


<<...more ranting snipped...>>

--

Rick C

[Cecil Bayona]

I think you missed his point he is referring to a primitive that
executes different things according to a set of conditions that is very
difficult in a CPU that is trying to be simple and execute an
instruction in one clock cycle. In a CPU where multiple clocks cycles
are used to execute the instruction then that may not a major issue but
a primitive Forth CPU with a single clock cycle to the instruction it
would be difficult at best.

--
Cecil - k5nwa

[rickman]

On 4/25/2017 4:57 PM, Cecil Bayona wrote:
>
> One cannot write every detail of the software writing process in a email
> or news post, if I did I would have a book, picking at little details
> because it was not mentioned does not mean I'm not aware of them.
> Remember that, it makes for a more pleasant conversation.

I can only read what you write. This is a great example. You seem to
be addressing something I wrote, but you have not indicated what it was.
So I have no idea what you are referring to and can only speculate.

> I have mentioned it here before when I write software I even have a
> notebook with all the software requirements, all the details of the
> software methodology including flowcharts and UML charts, I use State
> Diagrams when needed to document program/data triggers, and the source
> is well documented so I do plan the software well, but we are humans and
> we can make mistakes with the best of intentions.

That's great. But we were discussing methods, not necessarily *your*
methods. If you talk about coding from the top down interfering with
testing that is the issue I respond to without knowing anything of how
you design.

> Some languages are more prone than others to allow mistakes to slip by,
> C is well known for that. I always write my Forth applications bottom up
> because Forth allows me to, I prefer writing software bottom up when
> it's practical because it eliminates a lot of low level mistakes and
> actually works quite well doing so.

You can code C from the bottom up. The mistakes people make when coding
C have to do with the people. C does not force you to make mistakes.
There are methods of avoiding mistakes in C just as there are in any
language. I think Forth leaves the doors wide open in that regard so
why isn't Forth a language where you are prone to making uninitialized
pointer mistakes?

--

Rick C

[hughag...@gmail.com]

One of the easiest ways to avoid making mistakes when writing software, is to not write any software --- this seems to be Rickman's strategy.

It is an easy thing to write long-winded posts on comp.lang.forth explaining that somebody (Cecil in this case) is a bad programmer who makes a lot of mistakes --- it is much more difficult to write code without mistakes --- if Cecil has written software that works, then I'm impressed (even if it was in Pascal, which isn't really my cup of tea), because I know from experience that this is not easy in any language.

Debugging has always been the difficult part of programming. Everybody has written code that seemed brilliant, but then found that it didn't work and they didn't know why --- in this case you have to debug it --- many would-be programmers give up and just stop programming, then they spend the rest of their lives on the internet pretending to be big experts on programming...

[Ilya Tarasov]

> Ah, but I wasn't saying it was the best rifle/carbine probably it's
> quite capable on handling close up problems, even the Russians did not
> used it as a sniper rifle but instead use varios rifles mostly bolt
> action for sniper duty. The M1 Garand is probably what you are referring
> to, reliable and quite accurate.
>
> In bolt action rifles of WWII then the Mouser 98 was a great rifle and
> action, but often overlooked is the British Lee Enfield 4 which had many
> advance features.

Kalashnikov is enormous reliable and hard. It is not too precise, but it is just another goal - to have at least something shooting rather than high-quality but tends to be broken suddenly. Sniper rifle is for snipers.