On Monday, October 2, 2023 at 3:30:14 AM UTC-7, Hans Bezemer wrote:
> I subscribe to your idea that it's not a good idea to redefine
> (standard) words
> ...
> So, where <#, # and #> are concerned - I'm pretty happy with them.

ANS-Forth was designed for the PDP-11.
As I mentioned before, the lack of a double-stack was due to
Charles Moore not having an available register to use as the
double-stack pointer.
Another weakness of the PDP-11 is that it only addressed 64KB
of memory, that had to contain the compiler, the RTOS, and the
application program. This is why PolyForth for the 8086 used only
64KB (all segment registers set the same) --- PolyForth for the 8086
was just a line-by-line port of Charles Moore's PDP-11 Forth.

The assumption of having only 64KB total is why ANS-Forth lacks
a circular buffer for strings (UR/Forth had this). There wasn't enough
memory available, so <# #> used a static buffer for strings. This is stupid!
If you have a string from <# #> you have to manually store it somewhere
before you can do another <# #> or it will get over-written. Also, you
can't nest <# #> within each other. Anybody who claims to be "pretty happy"
with <# #> in the post-PDP-11 era (after 1982) is utterly incompetent.
Anybody who says that it is not a good idea to redefine ANS-Forth words
is a disgusting little sycophant of Elizabeth Rather --- not a Forth programmer!

In the novice-package I rewrote almost all of the ANS-Forth standard words.
I have a circular buffer for strings that WORD and <# #> etc. use. The user can
also generate his own strings concatenating many strings together. The buffer
is pretty big (because post-PDP-11 computers have a lot of memory) so it takes
a while for it to circle around and over-write strings --- it is not for permanent
storage of strings, but it holds strings long enough for multiple strings to be
generated and concatenated in various ways. Later on I wrote STRING-STACK.4TH
that is does pattern-matching, string-extraction and string construction.
STRING-STACK.4TH largely obsoletes the circular string-buffer.

Note that in the waning days of the PDP-11 there was a version with
bank-switching, but this was clunky in the usual clunky way of bank-switching
and was not competitive with the i8086 or MC68000 --- too little to late!

Note also that it was Raimond Dragomir who helped me get the
nesting of buffer-string generation to work smoothly --- I had that
feature, but in a clunky way --- he improved my code.
I'm willing to give Raimond Dragomir credit for his contribution to the
novice-package because he is not a typical maintenance programmer
who makes one minor contribution and then tries to take credit for
the entire package claiming to be far superior to the original programmer.
He is the only person on c.l.f. who is honorable in this way.

On Monday, October 2, 2023 at 4:18:15 AM UTC-7, Hans Bezemer wrote:
> Let's assume [STRING-STACK.4TH] is much faster [than Hans' string-stack
> that moves entire strings around]
> (which I doubt, considering the massive amount of code it takes).
> ...
> That, Hugh is the reason why I think this is well deserved:
> "What's dumb is that you think that the most elaborate algorithm is the best
> choice in all situations".

I think that Hans Bezemer should get a job at Testra!
He and John Hart think alike!
Testra would finally have found the "team player" that they have always wanted!

John Hart wrote a simulator for microprocessor code. He was using the
8086 SCASB instruction with REPZ to search his table for matching opcodes.
I said that a binary search would be faster. He said no, using the same
kind of thinking that Hans Bezemer uses. To paraphrase:
"I doubt that a binary search would be faster than a sequential search
considering the massive amount of code that it takes. You always want to
use the most elaborate algorithm --- this is beyond my comprehension!"

This was discussed in this thread:
https://groups.google.com/g/comp.lang.forth/c/s-6k_wdyrlE/m/tgZJ37jFAwAJ
Actually, "discussed" isn't the correct word because John Hart never
defended his use of a sequential search instead of a binary search.

On Saturday, May 13, 2023 at 1:43:34 PM UTC-7, Hugh Aguilar wrote:
> On Friday, May 12, 2023 at 3:53:36 PM UTC-7, John Hart wrote:
> > Something more compact and efficient than a CASE statement was
> > needed for defining logic equations in the FPGA4th system.
> > The solution was a set of words to build a look up table.
> >
> > key MAP[ n \ begins the process of building the table.
> > a b MAP \ associates a with b
> > c d MAP \ associates c with d
> > e ]MAP \ ends the look up table process
> > note: n specifies the key size (2^n) 0 = 1 byte, 1 = 2 bytes, 2 = 4 bytes
> >
> > At runtime, if the key = a, b is returned, if the key isn't found, e is returned
> >
> > Two more words to complete the set.
> > a ]: starts compilation of code associated with a
> > ;[ ends compilation
> >
> > : ALU { a b cmd - - c } \ example
> > cmd MAP[ 1
> > O ]: a b + ;[ MAP \ add
> > 1 ]: a b - ;[ MAP \ sub
> > 2 ]: a b AND ;[ MAP \ and
> > 3 ]: a b OR ;[ MAP \ or
> > ]: 0 ;[ ]MAP
> > EXECUTE
> > ;
> >
> > jrh
> Way back in 1994 you told me that you had a super-fast jump-table look-up
> that could be used for simulating a processor. You recommended that I use
> this to simulate the MiniForth. You were using a sequential look-up!!!
> I pointed out that a binary search would be much faster. You said that what
> you had was "super fast" because the 8086 has an instruction that does
> a sequential search on a 16-bit number. That was dumb! A binary search is
> still going to be faster, except possibly for a very small array of numbers.
>
> My FAST-SWITCH> (a jump table) and SLOW-SWITCH> (a sorted array and
> a binary search) is posted here:
> https://groups.google.com/g/comp.lang.forth/c/HwxAddZ54mg/m/Fmg5xT08AAAJ
> I'm far ahead of you.
> Your MAP[ mentioned above is what you had in 1994. It wasn't any good then either.
>
> What is your point in posting on comp.lang.forth???
> You don't have anything to offer.

On Monday, October 2, 2023 at 6:41:09 PM UTC+2, Hugh Aguilar wrote:
> On Monday, October 2, 2023 at 3:30:14 AM UTC-7, Hans Bezemer wrote:
> Also, you
> can't nest <# #> within each other. Anybody who claims to be "pretty happy"
> with <# #> in the post-PDP-11 era (after 1982) is utterly incompetent.

That, Hugh is the reason why I think this is well deserved: "What's dumb is
that you think that the most elaborate algorithm is the best choice in all situations".

As a matter of fact, that whole thing bugged me once. In all those years

> Anybody who says that it is not a good idea to redefine ANS-Forth words
> is a disgusting little sycophant of Elizabeth Rather --- not a Forth programmer!

You know you will have to support that proposition with some proper arguments.
First, you will have to define what a Forth programmer is. I don't think you will
come up with a widely accepted definition - unless it's an extensional one like:

"The only Forth programmer is Hugh". But I don't think you can get away with
that one - only if it were for the simple reason that the guy who invented it wasn't
called Hugh.

Second, I guess in order to be a "little sycophant of Elizabeth Rather"
you will have to prove some kind of relationship to Elizabeth Rather and quite
a number of other people - which are largely unknown to you. So I guess you
won't meet any juridical standards here. Sorry, that argument is moot as well.

Remains that it may or may not be a good idea to redefine ANS-Forth words.

Well, it depends. There is always a trade-off. On one hand, you might get the
behavior you want - which is nice. On the other hand, porting code is not that
easy. As a guy who added half a novel to his manual to point out all the differences
I think I have some experience in that regard - and hence are better equipped to
point out the advantages and disadvantages than most others.

Hans Bezemer

On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> John Hart wrote a simulator for microprocessor code. He was using the
> 8086 SCASB instruction with REPZ to search his table for matching opcodes..
> I said that a binary search would be faster. He said no, using the same
> kind of thinking that Hans Bezemer uses. To paraphrase:
> "I doubt that a binary search would be faster than a sequential search
> considering the massive amount of code that it takes. You always want to
> use the most elaborate algorithm --- this is beyond my comprehension!"

It depends on the number of opcodes you have to search. I spend a chapter
in my manual explaining it. The fastest is of course direct access - where the
thing to search is an index to a table.

If you can't do that, CASE..ENDCASE may be your friend. I found a binary search
paying off after about 100 entries - but not before. So a sequential search can
be faster in some cases. Just test it. "Meten is weten".

In the uBasic/4tH interpreter I used just about any technique in the book to speed
it up.

Hans Bezemer

On 02/10/2023 18:33, Hans Bezemer wrote:
> On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
>> John Hart wrote a simulator for microprocessor code. He was using the
>> 8086 SCASB instruction with REPZ to search his table for matching opcodes.
>> I said that a binary search would be faster. He said no, using the same
>> kind of thinking that Hans Bezemer uses. To paraphrase:
>> "I doubt that a binary search would be faster than a sequential search
>> considering the massive amount of code that it takes. You always want to
>> use the most elaborate algorithm --- this is beyond my comprehension!"
>
> It depends on the number of opcodes you have to search. I spend a chapter
> in my manual explaining it. The fastest is of course direct access - where the
> thing to search is an index to a table.

>
> If you can't do that, CASE..ENDCASE may be your friend. I found a binary search
> paying off after about 100 entries - but not before. So a sequential search can
> be faster in some cases. Just test it. "Meten is weten".
>

A binary search tree (BST) should be faster than a binary search because
when searching, getting to the next node for comparison of keys is
simpler. A BST, at node i only has to calculate 2*i to go left or 2*i+1
to go right.

An example can be seen at:
https://github.com/gerryjackson/Forth-switch/blob/master/lib/bst.fth

--
Gerry

On 3/10/2023 3:41 am, Hugh Aguilar wrote:
> On Monday, October 2, 2023 at 3:30:14 AM UTC-7, Hans Bezemer wrote:
>> I subscribe to your idea that it's not a good idea to redefine
>> (standard) words
>> ...
>> So, where <#, # and #> are concerned - I'm pretty happy with them.
>
> ANS-Forth was designed for the PDP-11.
> As I mentioned before, the lack of a double-stack was due to
> Charles Moore not having an available register to use as the
> double-stack pointer.

Do you have a reference for that beyond "It's obvious"? Have you
done a cost/benefit analysis? You've blown the smoke-rings, now
let's have the data.

> Another weakness of the PDP-11 is that it only addressed 64KB
> of memory, that had to contain the compiler, the RTOS, and the
> application program. This is why PolyForth for the 8086 used only
> 64KB (all segment registers set the same) --- PolyForth for the 8086
> was just a line-by-line port of Charles Moore's PDP-11 Forth.

Forth Inc ported to many machines. They claim to have had the first
high-level language running on the 8086 when the part was still buggy.
When did you release your first forth for the PC?

On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
> On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> > John Hart wrote a simulator for microprocessor code. He was using the
> > 8086 SCASB instruction with REPZ to search his table for matching opcodes.
> > I said that a binary search would be faster. He said no, using the same
> > kind of thinking that Hans Bezemer uses. To paraphrase:
> > "I doubt that a binary search would be faster than a sequential search
> > considering the massive amount of code that it takes. You always want to
> > use the most elaborate algorithm --- this is beyond my comprehension!"
> It depends on the number of opcodes you have to search. I spend a chapter
> in my manual explaining it. The fastest is of course direct access - where the
> thing to search is an index to a table.
>
> If you can't do that, CASE..ENDCASE may be your friend. I found a binary search
> paying off after about 100 entries - but not before. So a sequential search can
> be faster in some cases. Just test it. "Meten is weten".
>
> In the uBasic/4tH interpreter I used just about any technique in the book to speed
> it up.
>
> Hans Bezemer

I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
is so incompetent that he would use a sequential search for 8-bit opcodes
in which the sparse jump-table is only 256 words.

"The fastest is of course direct access -
where the thing to search is an index to a table."

Thank you very much, Captain Obvious!

In my novice-package I have FAST-SWITCH> that uses a sparse jump-table
and SLOW-SWITCH> that uses a compacted jump-table with a
binary-search look-up.
Now, thanks to our Forth instructor Hans, we know what the names imply!
In that thread mentioned previously I provided the documentation for
my <SWITCH code:
https://groups.google.com/g/comp.lang.forth/c/s-6k_wdyrlE/m/tgZJ37jFAwAJ

In article <f0710b94-647c-4563-b613-696e8038e1f6n@googlegroups.com>,
Hugh Aguilar <hughaguilar96@gmail.com> wrote:
>On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
>> On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
>> > John Hart wrote a simulator for microprocessor code. He was using the
>> > 8086 SCASB instruction with REPZ to search his table for matching opcodes.
>> > I said that a binary search would be faster. He said no, using the same
>> > kind of thinking that Hans Bezemer uses. To paraphrase:
>> > "I doubt that a binary search would be faster than a sequential search
>> > considering the massive amount of code that it takes. You always want to
>> > use the most elaborate algorithm --- this is beyond my comprehension!"
>> It depends on the number of opcodes you have to search. I spend a chapter
>> in my manual explaining it. The fastest is of course direct access -
>where the
>> thing to search is an index to a table.
>>
>> If you can't do that, CASE..ENDCASE may be your friend. I found a
>binary search
>> paying off after about 100 entries - but not before. So a sequential
>search can
>> be faster in some cases. Just test it. "Meten is weten".
>>
>> In the uBasic/4tH interpreter I used just about any technique in the
>book to speed
>> it up.
>>
>> Hans Bezemer
>
>I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
>is so incompetent that he would use a sequential search for 8-bit opcodes
>in which the sparse jump-table is only 256 words.

In an assembler it is worth it using hash codes.
There are tools to generate a perfect hash... if you are after speed.

Groetjes Albert

>Hugh
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Tuesday, October 3, 2023 at 9:20:51 AM UTC+2, Hugh Aguilar wrote:

> In my novice-package I have FAST-SWITCH> that uses a sparse jump-table
> and SLOW-SWITCH> that uses a compacted jump-table with a
> binary-search look-up.
> Now, thanks to our Forth instructor Hans, we know what the names imply!
> In that thread mentioned previously I provided the documentation for
> my <SWITCH code:

Well, you don't need massive libs to do all that. You can do it just as well with
a page of code. I mean - you can even program a binary search recursive. I even
like it better when tables are exposed - rather than hidden behind an ugly
CASE..ENDCASE variant.

---8<---
_binarySearch Param(3) ' value, start index, end index
Local(1) ' The middle of the array

If c@ < b@ Then ' Ok, signal we didn't find it
Return (-1)
Else
d@ = SHL(b@ + c@, -1) ' Prevent overflow (LOL!)
If a@ < @(d@) Then Return (FUNC(_binarySearch (a@, b@, d@-1)))
If a@ > @(d@) Then Return (FUNC(_binarySearch (a@, d@+1, c@)))
If a@ = @(d@) Then Return (d@) ' We found it, return index!
EndIf
---8<---

As a matter of fact - I only introduced that CASE construct when I found out there are
situations where this is the fastest way to go. I *actually* did some timings - and
when doing a string table of less than 25 elements, sequential search is on average
faster. After that - sure, binary search rulez.

I haven't found a situation where sequential search beats CASE..ENDCASE in case
of integers. Up to a hundred elements, CASE..ENDCASE wins head down. And yes,
afterwards it's binary search all the way.

And yes, direct access is faster. However, it's not always obvious how you can use
that technique. E.g. this is a table that answers such a question rather than to compute it:

offset delimiters \ precalculated responses
0 c, 0 c, 0 c, 1 c, 0 c, 1 c, 0 c, 0 c, \ 32 - 39
1 c, 1 c, 1 c, 1 c, 1 c, 1 c, 0 c, 1 c, \ 40 - 47
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, \ 48 - 55
0 c, 0 c, 0 c, 1 c, 1 c, 1 c, 1 c, 0 c, \ 56 - 63
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, \ 64 - 71
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, \ 72 - 79
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 0 c, \ 80 - 87
0 c, 0 c, 0 c, 0 c, 0 c, 0 c, 1 c, \ 88 - 94
\ EQUALS +-*^/%=;(),<>#

I even got a lightning fast integer factorial function that is based on the same technique.
I don't need a Hug(h|e) SWITCH library to do all that for me.

Hans Bezemer

On Tuesday, October 3, 2023 at 2:01:05 AM UTC-7, none albert wrote:
> In an assembler it is worth it using hash codes.
> There are tools to generate a perfect hash... if you are after speed.

I'm talking about the simulator that looks up opcodes.
Albert van der Horst says "assembler" --- he may be confused
about what the topic of discussion is. I'm not talking about
the symbol table --- try to be more alert!

People are always telling me what I should do,
although they have done nothing.

A binary search, as I have in SLOW-SWITCH>, has predictable speed.
It is easy to calculate the worst-case speed (the maximum number
of comparisons), and the worst-case is not much worse than the
best-case. Consistency is more important than average speed
in a simulator because you may want to simulate the target processor
running at a certain Mhz., and simulate each instruction's speed
consistent to how many clock-cycles it takes on the target processor.
A hash-table could be used in a simulator, but it would be difficult
to predict the worst-case speed (a collision followed by a long
sequential search).

The hallmark of a script kiddie is to always say:
"there are tools available to generate perfect code..."
These tools might be generating a pile of crap. How do you know?
To get a good hash function there has to be an exploitable
bit-pattern in the values that you are running through your hash function.
In a simulator, these values are 32-bit opcodes. There may not be an
exploitable bit-pattern. If there is, it is going to be different for
every target processor. My novice-package is general-purpose code.
My SLOW-SWITCH> should work reasonably well on any target processor
so I'm happy with it --- of course, Elizabeth Rather hated the concept
of general-purpose code and said that a custom-written solution
is always better (certainly it is always more time-consuming and
error-prone to write).

As a practical matter, I don't care that much anyway. I am only interested
in 16-bit target processors, so I use FAST-SWITCH> every time --- the limit
for FAST-SWITCH> is 64K so it works for 16-bit opcodes and the table
is small enough (256KB) to easily fit on a modern desktop computer.

> First gain is a cat spinning. - the Wise from Antrim -

I still have no idea what this means.
It seems like pseudo-intellectual nonsense --- roughly comparable to
the nonsense that DXforth spouts --- the problem with comp.lang.forth
is too much cat-spinning and not enough code-writing.

In article <9176e0ac-11b5-4048-b3e6-c671ea59467bn@googlegroups.com>,
Hugh Aguilar <hughaguilar96@gmail.com> wrote:
>On Tuesday, October 3, 2023 at 2:01:05 AM UTC-7, none albert wrote:
>> In an assembler it is worth it using hash codes.
>> There are tools to generate a perfect hash... if you are after speed.
>
>I'm talking about the simulator that looks up opcodes.
>Albert van der Horst says "assembler" --- he may be confused
>about what the topic of discussion is. I'm not talking about
>the symbol table --- try to be more alert!
>
>People are always telling me what I should do,
>although they have done nothing.
>
>A binary search, as I have in SLOW-SWITCH>, has predictable speed.
>It is easy to calculate the worst-case speed (the maximum number
>of comparisons), and the worst-case is not much worse than the
>best-case. Consistency is more important than average speed
>in a simulator because you may want to simulate the target processor
>running at a certain Mhz., and simulate each instruction's speed
>consistent to how many clock-cycles it takes on the target processor.
>A hash-table could be used in a simulator, but it would be difficult
>to predict the worst-case speed (a collision followed by a long
>sequential search).

You are not paying attention. A perfect hash is O(1) time.

<Senseless insults snipped>

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Tuesday, 3 October 2023 at 5:20:51 pm UTC+10, Hugh Aguilar wrote:
> On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
> > On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> > > John Hart wrote a simulator for microprocessor code. He was using the

> > Hans Bezemer
> I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
> is so incompetent that he would use a sequential search for 8-bit opcodes
> in which the sparse jump-table is only 256 words.
> "The fastest is of course direct access -
> where the thing to search is an index to a table."
> Thank you very much, Captain Obvious!

Hugh, for my home computer like chip I originally aimed to use 8 bit codes as the upper bits of the address space, which is ok in simple tasks. I am expanded this to multiple 8 bit spaces, and 16 bits etc and other sophisticated schemes into something new. But, I prefered 10 and 20 bits.

On Wednesday, October 11, 2023 at 8:04:35 AM UTC-7, S wrote:
> On Tuesday, 3 October 2023 at 5:20:51 pm UTC+10, Hugh Aguilar wrote:
> > On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
> > > On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> > > > John Hart wrote a simulator for microprocessor code. He was using the
> > > Hans Bezemer
> > I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
> > is so incompetent that he would use a sequential search for 8-bit opcodes
> > in which the sparse jump-table is only 256 words.
> > "The fastest is of course direct access -
> > where the thing to search is an index to a table."
> > Thank you very much, Captain Obvious!
> Hugh, for my home computer like chip I originally aimed to use 8 bit codes
> as the upper bits of the address space, which is ok in simple tasks.
> I am expanded this to multiple 8 bit spaces, and 16 bits etc and other
> sophisticated schemes into something new. But, I prefered 10 and 20 bits.

Is this in Verilog? Do you support interrupts?
I have a design for a chip but I haven't built it due to not knowing Verilog.
I did write an assembler and simulator for it.
I'm interested in any design that has some creativity to it --- not just a
fork of the J1 processor.

My design is for the HX8K. It has especial support for a byte-code VM.
The idea is to have a 64KW external memory that holds the Forth compiler,
application code and data (more 64KW banks can be provided for large
amounts of data, but the Forth code has to be in the 0th bank).
The 8KW of internal memory is divided into 5KW for machine-code
and 3KW for data. ISRs and other speed-critical code are assembled.

On Thursday, October 12, 2023 at 12:53:28 PM UTC-4, Hugh Aguilar wrote:
> On Wednesday, October 11, 2023 at 8:04:35 AM UTC-7, S wrote:
> > On Tuesday, 3 October 2023 at 5:20:51 pm UTC+10, Hugh Aguilar wrote:
> > > On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
> > > > On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> > > > > John Hart wrote a simulator for microprocessor code. He was using the
> > > > Hans Bezemer
> > > I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
> > > is so incompetent that he would use a sequential search for 8-bit opcodes
> > > in which the sparse jump-table is only 256 words.
> > > "The fastest is of course direct access -
> > > where the thing to search is an index to a table."
> > > Thank you very much, Captain Obvious!
> > Hugh, for my home computer like chip I originally aimed to use 8 bit codes
> > as the upper bits of the address space, which is ok in simple tasks.
> > I am expanded this to multiple 8 bit spaces, and 16 bits etc and other
> > sophisticated schemes into something new. But, I prefered 10 and 20 bits.
> Is this in Verilog? Do you support interrupts?
> I have a design for a chip but I haven't built it due to not knowing Verilog.
> I did write an assembler and simulator for it.
> I'm interested in any design that has some creativity to it --- not just a
> fork of the J1 processor.
>
> My design is for the HX8K.

I'm curious. What did you put in your design that is specific for the HX8K?

> It has especial support for a byte-code VM.
> The idea is to have a 64KW external memory that holds the Forth compiler,
> application code and data (more 64KW banks can be provided for large
> amounts of data, but the Forth code has to be in the 0th bank).
> The 8KW of internal memory is divided into 5KW for machine-code
> and 3KW for data. ISRs and other speed-critical code are assembled.

Why external memory, rather than internal memory in a different FPGA? I think it is easy to find them with 64 kB of internal RAM.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

On Wednesday, October 11, 2023 at 10:30:21 AM UTC+2, none albert wrote:
> In article <9176e0ac-11b5-4048...@googlegroups.com>,
> Hugh Aguilar <hughag...@gmail.com> wrote:
> >On Tuesday, October 3, 2023 at 2:01:05 AM UTC-7, none albert wrote:
> >> In an assembler it is worth it using hash codes.
> >> There are tools to generate a perfect hash... if you are after speed.
> >
> >I'm talking about the simulator that looks up opcodes.
> >Albert van der Horst says "assembler" --- he may be confused
> >about what the topic of discussion is. I'm not talking about
> >the symbol table --- try to be more alert!
> >
> >People are always telling me what I should do,
> >although they have done nothing.
> >
> >A binary search, as I have in SLOW-SWITCH>, has predictable speed.
> >It is easy to calculate the worst-case speed (the maximum number
> >of comparisons), and the worst-case is not much worse than the
> >best-case. Consistency is more important than average speed
> >in a simulator because you may want to simulate the target processor
> >running at a certain Mhz., and simulate each instruction's speed
> >consistent to how many clock-cycles it takes on the target processor.
> >A hash-table could be used in a simulator, but it would be difficult
> >to predict the worst-case speed (a collision followed by a long
> >sequential search).
> You are not paying attention. A perfect hash is O(1) time.

Listening is not one of Hugh strengths. Changing the goalposts is. Praising and promoting his own pet libraries is. But listening? Not really..

Hans Bezemer
> Groetjes Albert
> --
> Don't praise the day before the evening. One swallow doesn't make spring.
> You must not say "hey" before you have crossed the bridge. Don't sell the
> hide of the bear until you shot it. Better one bird in the hand than ten in
> the air. First gain is a cat spinning. - the Wise from Antrim -

On Thursday, October 12, 2023 at 2:23:36 PM UTC-7, Lorem Ipsum wrote:
> On Thursday, October 12, 2023 at 12:53:28 PM UTC-4, Hugh Aguilar wrote:
> > My design is for the HX8K.
> I'm curious. What did you put in your design that is specific for the HX8K?

I'm curious. Why do you think that I'm going to respond to you?
I have told you dozens of times: PISS OFF!

> > It has especial support for a byte-code VM.
> > The idea is to have a 64KW external memory that holds the Forth compiler,
> > application code and data (more 64KW banks can be provided for large
> > amounts of data, but the Forth code has to be in the 0th bank).
> > The 8KW of internal memory is divided into 5KW for machine-code
> > and 3KW for data. ISRs and other speed-critical code are assembled.
> Why external memory, rather than internal memory in a different FPGA?
> I think it is easy to find them with 64 kB of internal RAM.

I think that you should just leave me alone --- nasty troll!

P.S. You are too stupid to know the difference between
64KB and 64KW. You don't known that there is a difference in price
between an 18-bit FPGA with 32KW of internal memory and the
16-bit HX8K with 8KW of internal memory.
I don't think that you are a programmer at all.
You are a total fake. PISS OFF!

On Friday, October 13, 2023 at 4:28:34 AM UTC+2, Hugh Aguilar wrote:
> I think that you should just leave me alone --- nasty troll!
There are plenty of people here that would like to be left alone too. By
a troll whose name shall not be mentioned.

> I don't think that you are a programmer at all.
> You are a total fake. PISS OFF!
Why do you think you're qualified in any way to judge people who've worked
for decades in that line of work? And why do you think people asked for that
judgement, value that judgement - or even care about that judgement?

Hans Bezemer

On Thursday, October 12, 2023 at 10:28:34 PM UTC-4, Hugh Aguilar wrote:
> On Thursday, October 12, 2023 at 2:23:36 PM UTC-7, Lorem Ipsum wrote:
> > On Thursday, October 12, 2023 at 12:53:28 PM UTC-4, Hugh Aguilar wrote:
> > > My design is for the HX8K.
> > I'm curious. What did you put in your design that is specific for the HX8K?
> I'm curious. Why do you think that I'm going to respond to you?
> I have told you dozens of times: PISS OFF!
> > > It has especial support for a byte-code VM.
> > > The idea is to have a 64KW external memory that holds the Forth compiler,
> > > application code and data (more 64KW banks can be provided for large
> > > amounts of data, but the Forth code has to be in the 0th bank).
> > > The 8KW of internal memory is divided into 5KW for machine-code
> > > and 3KW for data. ISRs and other speed-critical code are assembled.
> > Why external memory, rather than internal memory in a different FPGA?
> > I think it is easy to find them with 64 kB of internal RAM.
> I think that you should just leave me alone --- nasty troll!

You confuse me sometimes. You tell me not to respond to you, then you respond to me... which is it???

> P.S. You are too stupid to know the difference between
> 64KB and 64KW.

Yes, I missed that you were saying kW. So, how large are your words? If you say 18 bits, that's not likely. The iCE40 parts don't provide 9, 18 or 36 bit data paths like many other FPGAs.

> You don't known that there is a difference in price
> between an 18-bit FPGA with 32KW of internal memory and the
> 16-bit HX8K with 8KW of internal memory.

There are many prices for these devices. What you might not appreciate is that while Lattice prices through Digikey, may be close to actual prices you will get from other distribution, the prices for other brands are artificially high at Digikey, because they will negotiate better prices through other channels.

> I don't think that you are a programmer at all.
> You are a total fake. PISS OFF!

I thought we had discussed this before. I am a hardware designer who programs as needed. I typically use VHDL for hardware and forth for software. You have your own special standards for who you consider to be a "programmer". That's not important to me. I use software as a tool to get my work done. I'm not trying to achieve sainthood through programming.

I will say that from what you have described of your hardware designs, you are not much of a hardware designer. When I've tried to offer advice, you get cranky and refuse my suggestions. That's ok too. At least no one can blame me for your lack of progress.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

On 13/10/2023 6:41 pm, Hans Bezemer wrote:
> On Friday, October 13, 2023 at 4:28:34 AM UTC+2, Hugh Aguilar wrote:
>> I think that you should just leave me alone --- nasty troll!
> There are plenty of people here that would like to be left alone too. By
> a troll whose name shall not be mentioned.
>
>> I don't think that you are a programmer at all.
>> You are a total fake. PISS OFF!
>
> Why do you think you're qualified in any way to judge people who've worked
> for decades in that line of work? And why do you think people asked for that
> judgement, value that judgement - or even care about that judgement?

In any society the greatest insult is to be told one has 'achieved nothing'.

On Friday, October 13, 2023 at 12:41:11 AM UTC-7, Hans Bezemer wrote:
> On Friday, October 13, 2023 at 4:28:34 AM UTC+2, Hugh Aguilar wrote:
> > I don't think that you [Rick Collins] are a programmer at all.
> > You are a total fake. PISS OFF!

> Why do you think you're qualified in any way to judge people who've worked
> for decades in that line of work? And why do you think people asked for that
> judgement, value that judgement - or even care about that judgement?

If John Hart had said in 1994 that I'm in no way qualified to write software
except as a code-monkey who has to be told exactly what to do,
then MFX would not have been written. Neither of the two programmers
at Testra (John Hart and Steve Brault) were capable of writing MFX.

I can easily see that Rick Collins is a total fake.
He has never written any Forth code that anybody has ever seen.
You are a total fake too --- you produce instructional videos in which
you teach us that your 8086 Forth is "Harvard Architecture."

During my job interview at Testra, John Hart told me that Tom Hart
had written a text user-interface package in UR/Forth that he was
very proud of, and he asked me if I wanted to become an expert in
using it. I said: "No!" John Hart laughed and said: "Nobody ever does."
I knew at that time that Tom Hart was a total fake. This was confirmed
during my lengthy employment there when I saw Tom Hart show up
every couple of weeks to spend a couple of hours acting like a big boss,
but he never wrote any code or did any hardware design or made any
technical contribution whatsoever.

Tom Hart responded to Juergen Pintaske as his peer.
This is because Juergen Pintaske is totally focused on the idea
that a programmer needs validation from somebody important
to be considered to be a programmer, and Tom Hart felt flattered
that Juergen Pintaske considered him to be that important person.
Juergen Pintaske felt flattered that Tom Hart responded to him
because most people ignore him. Tom Hart and Juergen Pintaske
mutually flattered each other --- effectively jerking each other off.

Juergen Pintaske contacted your employer and tried to convince
them to denounce you on comp.lang.forth the same way that
he convinced Tom Hart to denounce me on comp.lang.forth.
They did not respond to him.
Now you support Juergen Pintaske in attacking me.
Why don't you just be a man an admit that you have been wrong
in your understanding of Harvard Architecture? Would it really
kill you to admit your mistake? Instead you persist in being
wrong, making a complete fool out of yourself --- and you ally
yourself with Juergen Pintaske in attacking me to appease him
so that he stops attacking you. Coward!

On Saturday, October 14, 2023 at 2:12:44 AM UTC+2, Hugh Aguilar wrote:
> I can easily see that Rick Collins is a total fake.
> He has never written any Forth code that anybody has ever seen.
I know of another guy who says he's written "fast switch" libs and "string
stack" libs - and nobody has ever seen the code. It seems Rick is not the
only fake wandering around in this forum.

> You are a total fake too --- you produce instructional videos in which
> you teach us that your 8086 Forth is "Harvard Architecture."
Last time, I was thinking of challenging dxforth to take a bet with me
that you would bring this up again. Gee - I should have done that! Darn!

And I've had my own Forth compiler since 1994. I don't need to blame
another vendor if my pet code doesn't work anymore. So who is the
fake here?

> Juergen Pintaske contacted your employer and tried to convince
> them to denounce you on comp.lang.forth the same way that
> he convinced Tom Hart to denounce me on comp.lang.forth.
> They did not respond to him.
I've been playing the corporate game for decades now. It comes with
the job. Did "I've never written any Forth" really think I wouldn't be
prepared? Think again.

> Now you support Juergen Pintaske in attacking me.
I'm not attacking you. I've been trying for ages to talk some sense
into you. But like I said before: you-just-don't-listen. You've been
making a fool of yourself for ages - and you don't even seem to get
it.

So - that was fun. If you want to get serious, lemme know.

Hans Bezemer

On Saturday, October 14, 2023 at 11:41:47 AM UTC-4, Hans Bezemer wrote:
>
> I'm not attacking you. I've been trying for ages to talk some sense
> into you. But like I said before: you-just-don't-listen. You've been
> making a fool of yourself for ages - and you don't even seem to get
> it.

It's not just himself who is being made a fool of. We (anyone to responds to him) are the fools.

I would love to have a rational discussion with him. But there's always something that triggers his delusions of persecution. I think he is afraid of a discussion with me ever since he complained about some "inefficient" code I posted, where his approach had exactly the same issue. Others chimed into to point out that our code worked identically and he simply stopped replying. The reality is it was no big deal. It was just the hypocrisy of his remarks that made everyone dump on him.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

On Sunday, October 15, 2023 at 7:30:28 AM UTC+2, Lorem Ipsum wrote:

> It's not just himself who is being made a fool of. We (anyone to responds to him) are the fools.
I consider that a defensible position.

> I would love to have a rational discussion with him. But there's always
> something that triggers his delusions of persecution.
Well, that's true. He certainly has some trigger points - although they
differ per person. He also sees alliances where there are none. Most of
us have only communicated here in the open - without using any other
channels of communications. But he sees them conspiring behind his
back - with the only objective to damage him.

I can't deny there are some toxic elements here that are certainly out to
damage people. That having said, it's not the majority of people he has
a beef with.

>I think he is afraid of a discussion with me ever since he complained
> about some "inefficient" code I posted, where his approach had
> exactly the same issue. Others chimed into to point out that our code
> worked identically and he simply stopped replying.
There are several "tactics" he uses. One is "moving the goalposts", the
other is "plain contradiction". And yes, once cornered he just disappears -
or plainly ignores any sensible arguments as if they've never been uttered.

The sad thing is - although he has said and done despicable things to
people, I've seen him operate once in quite a different way. I can just
hope he starts to operate in a more constructive way some day. I still
think he has that capacity - although there are plenty of reasons to
differ with this point of view, since he's been going on in this fashion
for so long. It's kind of sad.

Hans Bezemer

On Friday, 13 October 2023 at 2:53:28 am UTC+10, Hugh Aguilar wrote:
> On Wednesday, October 11, 2023 at 8:04:35 AM UTC-7, S wrote:
> > On Tuesday, 3 October 2023 at 5:20:51 pm UTC+10, Hugh Aguilar wrote:
> > > On Monday, October 2, 2023 at 10:33:55 AM UTC-7, Hans Bezemer wrote:
> > > > On Monday, October 2, 2023 at 7:04:44 PM UTC+2, Hugh Aguilar wrote:
> > > > > John Hart wrote a simulator for microprocessor code. He was using the
> > > > Hans Bezemer
> > > I meant SCASW not SCASB --- these were 16-bit opcodes --- not even John Hart
> > > is so incompetent that he would use a sequential search for 8-bit opcodes
> > > in which the sparse jump-table is only 256 words.
> > > "The fastest is of course direct access -
> > > where the thing to search is an index to a table."
> > > Thank you very much, Captain Obvious!
> > Hugh, for my home computer like chip I originally aimed to use 8 bit codes
> > as the upper bits of the address space, which is ok in simple tasks.
> > I am expanded this to multiple 8 bit spaces, and 16 bits etc and other
> > sophisticated schemes into something new. But, I prefered 10 and 20 bits.
> Is this in Verilog? Do you support interrupts?
> I have a design for a chip but I haven't built it due to not knowing Verilog.
> I did write an assembler and simulator for it.
> I'm interested in any design that has some creativity to it --- not just a
> fork of the J1 processor.
>
> My design is for the HX8K. It has especial support for a byte-code VM.
> The idea is to have a 64KW external memory that holds the Forth compiler,
> application code and data (more 64KW banks can be provided for large
> amounts of data, but the Forth code has to be in the 0th bank).
> The 8KW of internal memory is divided into 5KW for machine-code
> and 3KW for data. ISRs and other speed-critical code are assembled.

Sorry Hugh, I completely missed this. I was coming back here to tell you,
that it is obvious you are being persecuted. But, don't worry about the last
20 years, it's the next 20 years you need to concentrate on. Forget these
people, make something good, and bring it out, but don't give up your
present business.

Anyway, back to your reply. I have just figured out the ISA/processing flow
schemes, that's where it starts. I was sharing from my experience a way to
overcome the 8 bit limitations. I've had numerous problems since covid (again)
and am only just getting well enough again to do more work on my legal issue.
So, I've basically had to give up helping my others and myself, to address this.
I'm a pretty much help a chunk of people sort, but unfortunately, people not like
that tend to block the way.

Now, your design. Is the 8 or 5k is divided by 256? I wasn't so good last time to
access my design memory properly, and should have suggested a seperate vector
address space for the 256 locations or 16 or more bits each. This is a seperate bus,
and can even be associative memory, so it passes onto the address bus, it can even
Be that the 8 bit location call forms the upper 8 bits of available memory and the
matching 8 bit location forms the offset. The issue is, without the vector locations,
dividing the address space by 256, is an inefficient use of space, as routines will often
not fit the space slot, and encroach on other slots. To use the encroached slot, you
need an offset, if any room is left, or use a 16 bit vector table. But, to reduce size of the
cpu 8 bit vectors in common memory, would be simpler. What you want, is a way to get
the address in the slot into the address bus for next cycle. That would require some
fancy hard like wiring, but as you are using fpga (is it) the forth cpu cycle should be
so much slower, that you could run a seperate memory controller to see the 8 bit call
coming in and in parallel at shorter cycle, load up the vector on the address bus next
cycle, rather than take an extra 1-2 cycles to complete. It's all reduced size or increased
performance. I try more sophisticated things to get many 8 bit call spaces, but one
thing you should look at with these schemes, for code cross compatibility between
spaces, is too declare the length, and maybe the start, of a code space to be divided
up by 256. So, your 5k gets divided up by 256 by the compiler. But, now it becomes a
pointer and as simple as mask bits to determine where the 8 bits go. Now, the 5k
program can fit anywhere in any practical memory configuration.

If you don't mind me asking, what do you plan to do with the processor?

I wouldn't mind using some of these foga processors if they could get those 4 bit
Chinese chip manufacturers (or watch chip manufacturers), with old chip equipment,
to make a descent version of them, with memory inci style with simple graphics and
sound (maybe with vectors). That's like 6000+ transistors plus memory. As I have
said before, it is as simple as packaging a psram die in the same package as the
processor, even two of them as a separate workspace, you could use as a graphics
buffer buffer, or other use, with dma. I think I was planning on hitting them up at one
stage with the idea of implementing one of the open source designs. Just another
exotic cheap chip, with performance, to sell.

Huge, I encourage you to go somewhere with it.

On Saturday, October 14, 2023 at 10:12:44 AM UTC+10, Hugh Aguilar wrote:

Hugh. How much energy and clock speed were you achieving on the PLD designs?