Re: FPGA4th

[Jurgen Pitaske]

On Thursday, 25 November 2021 at 07:06:47 UTC, johnro...@gmail.com wrote:
> \ Op Code File for MFX. Generated by MAKE-OPS v13
>
> \ MODELS\RACE32\RACE32.ops
>
> \ src dst codes J I H G F E D C B A 9 8 7 6 5 4 3 2 1 0
> \ `--.--' `-.-' | | | | | | | | | | |
> \ errors -------------' | | | | | | | | | | | |
> \ constants -----------------' | | | | | | | | | | | - c8_6_5_3
> \ stack ptr mem ---------------------' | | | | | | | | | | - S PM
> \ loop ctr ----------------------------' | | | | | | | | | - L LC
> \ return reg ----------------------------' | | | | | | | | - R RR
> \ prog ctr --------------------------------' | | | | | | | - P PC
> \ mem ads -----------------------------------' | | | | | | - F FLG
> \ flag ----------------------------------------' | | | | | - M MA
> \ carry -----------------------------------------' | | | | - C CRY
> \ data reg ----------------------------------------' | | | - D DR
> \ Treg high (sos) -----------------------------------' | | - T TH
> \ Treg low (sos) --------------------------------------' | - t TL
> \ accumulator (tos) -------------------------------------' - A AC
>
> \ Deferred cmds:
> \ Dsrc Ddst codes J I H G F E D C B A 9 8 7 6 5 4 3 2 1 0
> \ `--.--' `-.-' | | | | | | |
> \ errors -------------' | | | | | | | |
> \ constants -----------------' | | | | | | |
> \ i/o -------------------------------------' | | | | | |
> \ static mem --------------------------------' | | | | |
> \ dynamic mem ---------------------------------' | | | |
> \ reg mem ---------------------------------------' | | |
> \ Treg high (sos) -----------------------------------' | |
> \ Treg low (sos) --------------------------------------' |
> \ accumulator (tos) -------------------------------------'
>
> \ now deferred now deferred
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 0 1 >XBCS tT D - - H" TR>DR" ' EMU_TR>DR ' NOP SIMPLE-OP: TR>DR
> 1 1 >XBCS D tT - - H" DR>TR" ' EMU_DR>TR ' NOP SIMPLE-OP: DR>TR
> 2 1 >XBCS A D - - H" AC>DR" ' EMU_AC>DR ' NOP SIMPLE-OP: AC>DR
> 3 1 >XBCS A F - - H" TR15>FLG" ' EMU_TR15>FLG ' NOP SIMPLE-OP: TR15>FLG
> 1 2 >XBCS - tT - - H" -1>TRL" ' EMU_-1>TRL ' NOP SIMPLE-OP: -1>TRL
> 2 2 >XBCS - tT - - H" -1>TRH" ' EMU_-1>TRH ' NOP SIMPLE-OP: -1>TRH
> 3 2 >XBCS - tT - - H" -1>TR" ' EMU_-1>TR ' NOP SIMPLE-OP: -1>TR
> 0 3 >XBCS - D - - H" 0>DR" ' EMU_0>DR ' NOP SIMPLE-OP: 0>DR
> 1 3 >XBCS - tT - - H" 0>TRL" ' EMU_0>TRL ' NOP SIMPLE-OP: 0>TRL
> 2 3 >XBCS - tT - - H" 0>TRH" ' EMU_0>TRH ' NOP SIMPLE-OP: 0>TRH
> 3 3 >XBCS - tT - - H" 0>TR" ' EMU_0>TR ' NOP SIMPLE-OP: 0>TR
> 0 4 >XBCS A D - - H" AC>DR" ' EMU_AC>DR ' NOP SIMPLE-OP: AC>DR
> 1 4 >XBCS A tT - - H" AC>TR" ' EMU_AC>TR ' NOP SIMPLE-OP: AC>TR
> 2 4 >XBCS AtT D - - H" AC_OR_TR>DR" ' EMU_AC_OR_TR>DR ' NOP SIMPLE-OP: AC_OR_TR>DR
> 3 4 >XBCS AD tT - - H" AC_AND_DR>TR" ' EMU_AC_AND_DR>TR ' NOP SIMPLE-OP: AC_AND_DR>TR
> 0 5 >XBCS - C - - H" 0>CRY" ' EMU_0>CRY ' NOP SIMPLE-OP: 0>CRY
> 1 5 >XBCS - C - - H" 1>CRY" ' EMU_1>CRY ' NOP SIMPLE-OP: 1>CRY
> 2 5 >XBCS C CF - - H" 0>CRY>FLG" ' EMU_0>CRY>FLG ' NOP SIMPLE-OP: 0>CRY>FLG
> 3 5 >XBCS CF CF - - H" CRY><FLG" ' EMU_CRY><FLG ' NOP SIMPLE-OP: CRY><FLG
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 0 6 >XBCS c6 L - - H" C6>REP" ' EMU_C6>REP ' NOP SIMPLE-OP: C6>REP
> 1 6 >XBCS Ac6 DL - - H" C6>REP~AC>DR" ' EMU_C6>REP~AC>DR ' NOP SIMPLE-OP: C6>REP~AC>DR
> 2 6 >XBCS tTc6 DL - - H" C6>REP~TR>DR" ' EMU_C6>REP~TR>DR ' NOP SIMPLE-OP: C6>REP~TR>DR
> 3 6 >XBCS tTDc6 tTDL - - H" C6>REP~TR><DR" ' EMU_C6>REP~TR><DR ' NOP SIMPLE-OP: C6>REP~TR><DR
> 0 7 >XBCS AtTc6 DL - - H" C6&AC>REP~0>DR" ' EMU_C6&AC>REP~0>DR ' NOP SIMPLE-OP: C6&AC>REP~0>DR
> 1 7 >XBCS AtTc6 DL - - H" C6&/AC>REP~0>DR" ' EMU_C6&/AC>REP~0>D ' NOP SIMPLE-OP: C6&/AC>REP~0>DR
> 2 7 >XBCS c6 L - - H" C6>LOOP" ' EMU_C6>LOOP ' NOP SIMPLE-OP: C6>LOOP
> 8 >CS - - A r H" AC>*MA_d" ' EMU_AC>*MA ' EMU_WE4 SIMPLE-OP: AC>*MA_d
> 9 >CS A tT - - H" AC>TRx" ' EMU_AC>TR ' NOP SIMPLE-OP: AC>TRx
> 1 A >XBCS - - A rds H" AC>*MA_BYT_d" ' EMU_AC>*MA_BYT ' EMU_WE1 SIMPLE-OP: AC>*MA_BYT_d
> 2 A >XBCS - - A rdso H" ACLW>*MA_d" ' EMU_ACLW>*MA ' EMU_WE2 SIMPLE-OP: ACLW>*MA_d
> 3 A >XBCS - - A rdso H" ACHW>*MA_d" ' EMU_ACHW>*MA ' EMU_WE3 SIMPLE-OP: ACHW>*MA_d
> 1 B >XBCS A tT A r H" AC>TR~AC>*MA_d" ' EMU_AC>TR ' EMU_WE4 SIMPLE-OP: AC>TR~AC>*MA_d
> 2 B >XBCS A D A r H" AC>DR~AC>*MA_d" ' EMU_AC>DR ' EMU_WE4 SIMPLE-OP: AC>DR~AC>*MA_d
> 3 B >XBCS - - A - H" AC>TR(CS)_d" ' EMU_AC>TR(CS) ' EMU_WE7 SIMPLE-OP: AC>TR(CS)_d
> 1 C >XBCS - tT ro tT H" *MA>TRL_d" ' EMU_*MA>TRL ' EMU_RE1 SIMPLE-OP: *MA>TRL_d
> 2 C >XBCS - tT rds tT H" *MA>TRH_d" ' EMU_*MA>TRH ' EMU_RE2 SIMPLE-OP: *MA>TRH_d
> 3 C >XBCS - tT r tT H" *MA>TR_d" ' EMU_*MA>TR ' EMU_RE3 SIMPLE-OP: *MA>TR_d
> 1 D >XBCS A tTD r tT H" AC>DR~*MA>TR_d" ' EMU_AC>DR ' EMU_RE3 SIMPLE-OP: AC>DR~*MA>TR_d
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 2 D >XBCS tT tTD r tT H" TR>DR~*MA>TR_d" ' EMU_TR>DR ' EMU_RE3 SIMPLE-OP: TR>DR~*MA>TR_d
> F >CS - tT ro tT H" *MA>NXT_d" ' EMU_*MA>NXT ' EMU_RE4 SIMPLE-OP: *MA>NXT_d
> 0 10 >XBCS CPc6 P - - H" IF_CRY+JMP" ' EMU_IF_CRY+JMP ' NOP COUNT-OP: IF_CRY+JMP
> 1 10 >XBCS CPc6 P - - H" IF/CRY+JMP" ' EMU_IF/CRY+JMP ' NOP COUNT-OP: IF/CRY+JMP
> 2 10 >XBCS FPc6 P - - H" IF_FLG+JMP" ' EMU_IF_FLG+JMP ' NOP COUNT-OP: IF_FLG+JMP
> 3 10 >XBCS FPc6 P - - H" IF/FLG+JMP" ' EMU_IF/FLG+JMP ' NOP COUNT-OP: IF/FLG+JMP
> 0 11 >XBCS APc6 P - - H" IF_AC0+JMP" ' EMU_IF_AC0+JMP ' NOP COUNT-OP: IF_AC0+JMP
> 1 11 >XBCS APc6 P - - H" IF/AC0+JMP" ' EMU_IF/AC0+JMP ' NOP COUNT-OP: IF/AC0+JMP
> 2 11 >XBCS APc6 P - - H" IF_AC31+JMP" ' EMU_IF_AC31+JMP ' NOP COUNT-OP: IF_AC31+JMP
> 3 11 >XBCS APc6 P - - H" IF/AC31+JMP" ' EMU_IF/AC31+JMP ' NOP COUNT-OP: IF/AC31+JMP
> 0 12 >XBCS CPc6 P - - H" IF_CRY-JMP" ' EMU_IF_CRY-JMP ' NOP COUNT-OP: IF_CRY-JMP
> 1 12 >XBCS CPc6 P - - H" IF/CRY-JMP" ' EMU_IF/CRY-JMP ' NOP COUNT-OP: IF/CRY-JMP
> 2 12 >XBCS FPc6 P - - H" IF_FLG-JMP" ' EMU_IF_FLG-JMP ' NOP COUNT-OP: IF_FLG-JMP
> 3 12 >XBCS FPc6 P - - H" IF/FLG-JMP" ' EMU_IF/FLG-JMP ' NOP COUNT-OP: IF/FLG-JMP
> 0 13 >XBCS APc6 P - - H" IF_AC0-JMP" ' EMU_IF_AC0-JMP ' NOP COUNT-OP: IF_AC0-JMP
> 1 13 >XBCS APc6 P - - H" IF/AC0-JMP" ' EMU_IF/AC0-JMP ' NOP COUNT-OP: IF/AC0-JMP
> 2 13 >XBCS APc6 P - - H" IF_AC31-JMP" ' EMU_IF_AC31-JMP ' NOP COUNT-OP: IF_AC31-JMP
> 3 13 >XBCS APc6 P - - H" IF/AC31-JMP" ' EMU_IF/AC31-JMP ' NOP COUNT-OP: IF/AC31-JMP
> 0 14 >XBCS Pc8 P - - H" +JMP" ' EMU_+JMP ' NOP COUNT-OP: +JMP
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 1 14 >XBCS APc6 P - - H" IF/AC1+JMP" ' EMU_IF/AC1+JMP ' NOP COUNT-OP: IF/AC1+JMP
> 2 14 >XBCS APc6 P - - H" IF/AC2+JMP" ' EMU_IF/AC2+JMP ' NOP COUNT-OP: IF/AC2+JMP
> 3 14 >XBCS APc6 P - - H" IF/AC3+JMP" ' EMU_IF/AC3+JMP ' NOP COUNT-OP: IF/AC3+JMP
> 0 15 >XBCS APc6 P - - H" IF/AC4+JMP" ' EMU_IF/AC4+JMP ' NOP COUNT-OP: IF/AC4+JMP
> 1 15 >XBCS APc6 P - - H" IF/AC5+JMP" ' EMU_IF/AC5+JMP ' NOP COUNT-OP: IF/AC5+JMP
> 2 15 >XBCS APc6 P - - H" IF/AC6+JMP" ' EMU_IF/AC6+JMP ' NOP COUNT-OP: IF/AC6+JMP
> 3 15 >XBCS APc6 P - - H" IF/AC7+JMP" ' EMU_IF/AC7+JMP ' NOP COUNT-OP: IF/AC7+JMP
> 0 16 >XBCS Pc8 P - - H" -JMP" ' EMU_-JMP ' NOP COUNT-OP: -JMP
> 1 16 >XBCS PLc6 P - - H" IF_REP-JMP" ' EMU_IF_REP-JMP ' NOP COUNT-OP: IF_REP-JMP
> 2 16 >XBCS c8 P - - H" JMP&LINK" ' EMU_JMP&LINK ' NOP COUNT-OP: JMP&LINK
> 3 16 >XBCS R P - - H" RET_LINK" ' EMU_RET_LINK ' NOP COUNT-OP: RET_LINK
> 0 17 >XBCS t tT - - H" TR_RL" ' EMU_TR_RL ' NOP SIMPLE-OP: TR_RL
> 1 17 >XBCS At tT - - H" TR_RL_DR" ' EMU_TR_RL_DR ' NOP SIMPLE-OP: TR_RL_DR
> 2 17 >XBCS tD tT - - H" TR_RL_AC" ' EMU_TR_RL_AC ' NOP SIMPLE-OP: TR_RL_AC
> 3 17 >XBCS tTC tTC - - H" TR_RLC" ' EMU_TR_RLC ' NOP SIMPLE-OP: TR_RLC
> 0 18 >XBCS tT tT - - H" TR_RR" ' EMU_TR_RR ' NOP SIMPLE-OP: TR_RR
> 1 18 >XBCS tT tT - - H" TR_RR_DR" ' EMU_TR_RR_DR ' NOP SIMPLE-OP: TR_RR_DR
> 2 18 >XBCS tT tT - - H" TR_RR_AC" ' EMU_TR_RR_AC ' NOP SIMPLE-OP: TR_RR_AC
> 3 18 >XBCS tT tTC - - H" TR_RRC" ' EMU_TR_RRC ' NOP SIMPLE-OP: TR_RRC
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 0 19 >XBCS tT tT - - H" TR_RRB" ' EMU_TR_RRB ' NOP SIMPLE-OP: TR_RRB
> 1 19 >XBCS tT tT - - H" TR_RRB_DR" ' EMU_TR_RRB_DR ' NOP SIMPLE-OP: TR_RRB_DR
> 2 19 >XBCS tT tT - - H" TR_RRB_AC" ' EMU_TR_RRB_AC ' NOP SIMPLE-OP: TR_RRB_AC
> 3 19 >XBCS tT tT - - H" TR_SRB" ' EMU_TR_SRB ' NOP SIMPLE-OP: TR_SRB
> 0 1A >XBCS D D - - H" DR_RL" ' EMU_DR_RL ' NOP SIMPLE-OP: DR_RL
> 1 1A >XBCS D D - - H" DR_RL" ' EMU_DR_RL ' NOP SIMPLE-OP: DR_RL
> 2 1A >XBCS tD D - - H" DR_RL-TR" ' EMU_DR_RL_TR ' NOP SIMPLE-OP: DR_RL-TR
> 3 1A >XBCS DC DC - - H" DR_RLC" ' EMU_DR_RLC ' NOP SIMPLE-OP: DR_RLC
> 0 1B >XBCS D D - - H" DR_RR" ' EMU_DR_RR ' NOP SIMPLE-OP: DR_RR
> 1 1B >XBCS AD D - - H" DR_RR_AC" ' EMU_DR_RR_AC ' NOP SIMPLE-OP: DR_RR_AC
> 2 1B >XBCS TD D - - H" DR_RR_TR" ' EMU_DR_RR_TR ' NOP SIMPLE-OP: DR_RR_TR
> 3 1B >XBCS DC DC - - H" DR_RRC" ' EMU_DR_RRC ' NOP SIMPLE-OP: DR_RRC
> 0 1C >XBCS D D - - H" DR_RRB" ' EMU_DR_RRB ' NOP SIMPLE-OP: DR_RRB
> 1 1C >XBCS AD D - - H" DR_RRB_AC" ' EMU_DR_RRB_AC ' NOP SIMPLE-OP: DR_RRB_AC
> 2 1C >XBCS tD D - - H" DR_RRB_TR" ' EMU_DR_RRB_TR ' NOP SIMPLE-OP: DR_RRB_TR
> 3 1C >XBCS D D - - H" DR_SRB" ' EMU_DR_SRB ' NOP SIMPLE-OP: DR_SRB
> 2 1D >XBCS tD tTD - - H" TR_DR_RL_AC" ' EMU_TR_DR_RL_AC ' NOP SIMPLE-OP: TR_DR_RL_AC
> 0 1E >XBCS tTD tTD - - H" TR_DR_RR" ' EMU_TR_DR_RR ' NOP SIMPLE-OP: TR_DR_RR
> 2 1E >XBCS AtTD tTD - - H" TR_DR_RR_AC" ' EMU_TR_DR_RR_AC ' NOP SIMPLE-OP: TR_DR_RR_AC
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 2 1F >XBCS tTD tTD - - H" TR_DR_RRB_AC" ' EMU_TR_DR_RRB_AC ' NOP SIMPLE-OP: TR_DR_RRB_AC
> 0 >MA - M - - H" hold" ' EMU_MA>MA ' NOP JMPL-OP: hold
> 1 0 >MAPT A M - - H" IP>MA" ' EMU_PM>MA ' NOP JMPL-OP: IP>MA
> 1 1 >MAPT A M - - H" RP>MA" ' EMU_PM>MA ' NOP JMPL-OP: RP>MA
> 1 2 >MAPT A M - - H" SP>MA" ' EMU_PM>MA ' NOP JMPL-OP: SP>MA
> 1 3 >MAPT A M - - H" DP>MA" ' EMU_PM>MA ' NOP JMPL-OP: DP>MA
> 1 4 >MAPT Sc5 M - - H" MA+C>MA" ' EMU_MA+C>MA ' NOP JMPL-OP: MA+C>MA
> 1 5 >MAPT Sc5 M - - H" MA-C>MA" ' EMU_MA-C>MA ' NOP JMPL-OP: MA-C>MA
> 1 6 >MAPT Sc5 M - - H" MA+C>MAu" ' EMU_MA+C>MA ' NOP JMPL-OP: MA+C>MAu
> 1 7 >MAPT Sc5 M - - H" MA-C>MAu" ' EMU_MA-C>MA ' NOP JMPL-OP: MA-C>MAu
> 2 >MA M M - - H" AC>MA" ' EMU_AC>MA ' NOP JMPL-OP: AC>MA
> 3 >MA tTS M - - H" MA-TR>MAu" ' EMU_MA-TR>MA ' NOP JMPL-OP: MA-TR>MAu
> 4 >MA Mc6 M - - H" AC+C8>MA" ' EMU_AC+C8>MA ' NOP JMPL-OP: AC+C8>MA
> 5 0 >MAPT A M - - H" IP+2>MAu" ' EMU_PM+2>MA ' NOP JMPL-OP: IP+2>MAu
> 5 1 >MAPT tT M - - H" TR>MAu" ' EMU_TR>MA ' NOP JMPL-OP: TR>MAu
> 5 2 >MAPT tT M - - H" TR+2>MAu" ' EMU_TR+2>MA ' NOP JMPL-OP: TR+2>MAu
> 5 5 >MAPT tT M - - H" TR>MA" ' EMU_TR>MA ' NOP JMPL-OP: TR>MA
> 5 6 >MAPT tT M - - H" TR+2>MA" ' EMU_TR+2>MA ' NOP JMPL-OP: TR+2>MA
> 5 7 >MAPT S M - - H" MA+4>MA" ' EMU_MA+4>MA ' NOP JMPL-OP: MA+4>MA
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 6 0 >MAPT Ac5 M - - H" IP+C>MA" ' EMU_PM+C>MA ' NOP JMPL-OP: IP+C>MA
> 6 1 >MAPT Ac5 M - - H" RP+C>MA" ' EMU_PM+C>MA ' NOP JMPL-OP: RP+C>MA
> 6 2 >MAPT Ac5 M - - H" SP+C>MA" ' EMU_PM+C>MA ' NOP JMPL-OP: SP+C>MA
> 6 3 >MAPT Ac3 M - - H" DP+C5>MA" ' EMU_PM+C5>MA ' NOP JMPL-OP: DP+C5>MA
> 6 4 >MAPT Ac5 M - - H" IP+C>MAu" ' EMU_PM+C>MA ' NOP JMPL-OP: IP+C>MAu
> 6 5 >MAPT Ac5 M - - H" RP+C>MAu" ' EMU_PM+C>MA ' NOP JMPL-OP: RP+C>MAu
> 6 6 >MAPT Ac5 M - - H" SP+C>MAu" ' EMU_PM+C>MA ' NOP JMPL-OP: SP+C>MAu
> 6 7 >MAPT Ac3 M - - H" DP+C5>MAu" ' EMU_PM+C5>MA ' NOP JMPL-OP: DP+C5>MAu
> 7 0 >MAPT Ac5 M - - H" IP-C>MA" ' EMU_PM-C>MA ' NOP JMPL-OP: IP-C>MA
> 7 1 >MAPT Ac5 M - - H" RP-C>MA" ' EMU_PM-C>MA ' NOP JMPL-OP: RP-C>MA
> 7 2 >MAPT Ac5 M - - H" SP-C>MA" ' EMU_PM-C>MA ' NOP JMPL-OP: SP-C>MA
> 7 3 >MAPT Ac3 M - - H" DP-C5>MA" ' EMU_PM-C5>MA ' NOP JMPL-OP: DP-C5>MA
> 7 4 >MAPT Ac5 M - - H" IP-C>MAu" ' EMU_PM-C>MA ' NOP JMPL-OP: IP-C>MAu
> 7 5 >MAPT Ac5 M - - H" RP-C>MAu" ' EMU_PM-C>MA ' NOP JMPL-OP: RP-C>MAu
> 7 6 >MAPT Ac5 M - - H" SP-C>MAu" ' EMU_PM-C>MA ' NOP JMPL-OP: SP-C>MAu
> 7 7 >MAPT Ac3 M - - H" DP-C5>MAu" ' EMU_PM-C5>MA ' NOP JMPL-OP: DP-C5>MAu
> 1 >AC AM0 FM A - - H" MA>AC" ' EMU_MA>AC ' NOP SIMPLE-OP: MA>AC
> 2 0 >ACRA AM0 A AC - - H" AC-1>ACC" ' EMU_AC-1>ACC ' NOP SIMPLE-OP: AC-1>ACC
> 2 1 >ACRA AM0 A AC - - H" AC+1>ACC" ' EMU_AC+1>ACC ' NOP SIMPLE-OP: AC+1>ACC
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 2 2 >ACRA AM0 A A - - H" AC-1>AC" ' EMU_AC-1>AC ' NOP SIMPLE-OP: AC-1>AC
> 2 3 >ACRA AM0 A A - - H" AC+1>AC" ' EMU_AC+1>AC ' NOP SIMPLE-OP: AC+1>AC
> 2 4 >ACRA AM0 AC A - - H" AC+CRY>AC" ' EMU_AC+CRY>AC ' NOP SIMPLE-OP: AC+CRY>AC
> 2 5 >ACRA AM0 AC A - - H" AC+CRY>AC" ' EMU_AC+CRY>AC ' NOP SIMPLE-OP: AC+CRY>AC
> 2 7 >ACRA AM0 tT A - - H" TR+1>AC" ' EMU_TR+1>AC ' NOP SIMPLE-OP: TR+1>AC
> 3 1 >ACRA AM0 - A - - H" 0>AC" ' EMU_0>AC ' NOP SIMPLE-OP: 0>AC
> 3 2 >ACRA AM0 tT A - - H" TR>AC" ' EMU_TR>AC ' NOP SIMPLE-OP: TR>AC
> 3 3 >ACRA AM0 D A - - H" DR>AC" ' EMU_DR>AC ' NOP SIMPLE-OP: DR>AC
> 1 >AC AM1 C A - - H" CRY>AC" ' EMU_CRY>AC ' NOP SIMPLE-OP: CRY>AC
> 2 >AC AM1 tT A - - H" TR>ACx" ' EMU_TR>AC ' NOP SIMPLE-OP: TR>ACx
> 3 >AC AM1 D A - - H" DR>ACx" ' EMU_DR>AC ' NOP SIMPLE-OP: DR>ACx
> 1 >AC AM2 c8 A - - H" C8>AC" ' EMU_C8>AC ' NOP SIMPLE-OP: C8>AC
> 2 1 >ACRA AM2 AD A - - H" AC_XOR_DR>AC" ' EMU_AC_XOR_DR>AC ' NOP SIMPLE-OP: AC_XOR_DR>AC
> 2 2 >ACRA AM2 tT A - - H" TR+1>ACx" ' EMU_TR+1>AC ' NOP SIMPLE-OP: TR+1>ACx
> 2 4 >ACRA AM2 AtT AC - - H" AC-TR>ACC" ' EMU_AC-TR>ACC ' NOP SIMPLE-OP: AC-TR>ACC
> 2 5 >ACRA AM2 AtT AC - - H" AC+TR>ACC" ' EMU_AC+TR>ACC ' NOP SIMPLE-OP: AC+TR>ACC
> 2 6 >ACRA AM2 AtT A - - H" AC-TR>AC" ' EMU_AC-TR>AC ' NOP SIMPLE-OP: AC-TR>AC
> 2 7 >ACRA AM2 AtT A - - H" AC+TR>AC" ' EMU_AC+TR>AC ' NOP SIMPLE-OP: AC+TR>AC
> 1 0 >ACPT AM3 A A - - H" AC_SL" ' EMU_AC_SL ' NOP SIMPLE-OP: AC_SL
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 2 0 >ACPT AM3 AC AC - - H" AC_RLC" ' EMU_AC_RLC ' NOP SIMPLE-OP: AC_RLC
> 1 1 >ACPT AM3 A A - - H" AC_RL" ' EMU_AC_RL ' NOP SIMPLE-OP: AC_RL
> 2 1 >ACPT AM3 At A - - H" AC_RL_TR" ' EMU_AC_RL_TR ' NOP SIMPLE-OP: AC_RL_TR
> 3 1 >ACPT AM3 AD A - - H" AC_RL_DR" ' EMU_AC_RL_DR ' NOP SIMPLE-OP: AC_RL_DR
> 1 2 >ACPT AM3 A A - - H" AC_SR" ' EMU_AC_SR ' NOP SIMPLE-OP: AC_SR
> 2 2 >ACPT AM3 AC AC - - H" AC_RRC" ' EMU_AC_RRC ' NOP SIMPLE-OP: AC_RRC
> 1 3 >ACPT AM3 A A - - H" AC_RR" ' EMU_AC_RR ' NOP SIMPLE-OP: AC_RR
> 2 3 >ACPT AM3 AT A - - H" AC_RR_TR" ' EMU_AC_RR_TR ' NOP SIMPLE-OP: AC_RR_TR
> 3 3 >ACPT AM3 AD A - - H" AC_RR_DR" ' EMU_AC_RR_DR ' NOP SIMPLE-OP: AC_RR_DR
> 1 4 >ACPT AM3 A A - - H" AC_SRB" ' EMU_AC_SRB ' NOP SIMPLE-OP: AC_SRB
> 2 4 >ACPT AM3 A A - - H" AC_RRB" ' EMU_AC_RRB ' NOP SIMPLE-OP: AC_RRB
> 3 4 >ACPT AM3 AD A - - H" AC_RRB_AC" ' EMU_AC_RRB_AC ' NOP SIMPLE-OP: AC_RRB_AC
> 1 5 >ACPT AM3 At A - - H" AC_RRB_TR" ' EMU_AC_RRB_TR ' NOP SIMPLE-OP: AC_RRB_TR
> 2 5 >ACPT AM3 AD A - - H" AC_RRB_DR" ' EMU_AC_RRB_DR ' NOP SIMPLE-OP: AC_RRB_DR
> 1 6 >ACPT AM3 AtT A - - H" MPY>AC" ' EMU_MPY>AC ' NOP SIMPLE-OP: MPY>AC
> 2 6 >ACPT AM3 AtTDC A - - H" DIV>AC" ' EMU_DIV>AC ' NOP SIMPLE-OP: DIV>AC
> 7 5 2 >MAPTR - - - - H" RP-4>MAu" ' EMU_RP-4>MAu ' NOP SIMPLE-OP: RP-4>MAu
> 5 4 0 >MAPTR - - - - H" TR>MAu" ' EMU_TR>MAu ' NOP SIMPLE-OP: TR>MAu
> 6 5 2 >MAPTR - - - - H" RP+4>MAu" ' EMU_RP+4>MAu ' NOP SIMPLE-OP: RP+4>MAu
> \ code type src dst Dsrc Ddst instr string emultion emulation operation
> 5 4 1 >MAPTR - - - - H" TR+2>MAu" ' EMU_TR+2>MAu ' NOP SIMPLE-OP: TR+2>MAu
> 6 4 1 >MAPTR - - - - H" IP+2>MAu" ' EMU_IP+2>MAu ' NOP SIMPLE-OP: IP+2>MAu
> 1 6 1 >MAPTR - - - - H" MA+2>MAu" ' EMU_MA+2>MAu ' NOP SIMPLE-OP: MA+2>MAu
> 6 6 2 >MAPTR - - - - H" SP+4>MAu" ' EMU_SP+4>MAu ' NOP SIMPLE-OP: SP+4>MAu
> 6 6 4 >MAPTR - - - - H" SP+8>MAu" ' EMU_SP+8>MAu ' NOP SIMPLE-OP: SP+8>MAu
> 7 5 4 >MAPTR - - - - H" RP-8>MAu" ' EMU_RP-8>MAu ' NOP SIMPLE-OP: RP-8>MAu
> 7 6 2 >MAPTR - - - - H" SP-4>MAu" ' EMU_SP-4>MAu ' NOP SIMPLE-OP: SP-4>MAu
> 7 2 2 >MAPTR - - - - H" SP-4>MA" ' EMU_SP-4>MA ' NOP SIMPLE-OP: SP-4>MA
> 6 1 2 >MAPTR - - - - H" RP+4>MA" ' EMU_RP+4>MA ' NOP SIMPLE-OP: RP+4>MA
> 6 5 4 >MAPTR - - - - H" RP+8>MAu" ' EMU_RP+8>MAu ' NOP SIMPLE-OP: RP+8>MAu
> \ comment - - - - H" (SOS>TR)" ' EMU_(SOS>TR) ' NOP SIMPLE-OP: (SOS>TR)
> \ comment - - - - H" (PUSH}" ' EMU_(PUSH} ' NOP SIMPLE-OP: (PUSH}
> \ comment - - - - H" (POP)" ' EMU_(POP) ' NOP SIMPLE-OP: (POP)
> \ comment - - - - H" (RP@>TR)" ' EMU_(RP@>TR) ' NOP SIMPLE-OP: (RP@>TR)
> 0 >XB - - - - H" AMD0_d" ' EMU_AMD0 ' EMU_dfr SIMPLE-OP: AMD0_d
> 1 >XB - - - - H" AMD1_d" ' EMU_AMD1 ' EMU_dfr SIMPLE-OP: AMD1_d
> 2 >XB - - - - H" AMD2_d" ' EMU_AMD2 ' EMU_dfr SIMPLE-OP: AMD2_d
> 3 >XB - - - - H" AMD3_d" ' EMU_AMD3 ' EMU_dfr SIMPLE-OP: AMD3_d
> Done


Thank you very much John - let's see what happens next.
Just for the fun of it I formatted it slightly in a way that makes the blocks a bit clearer to me
https://www.dropbox.com/sh/ah8umk0hgq1818s/AAC8nNEueZZcIYJ8uGP4F4wPa?dl=0

[A.T. Murray]

Forth AI coder's note:
FPGA stands for field-programmable gate array.

Mentifex
--
http://github.com/kernc/mindforth/tree/master/wiki
http://ai.neocities.org/mindforth.txt -- MindForth free AI source code
http://dl.acm.org/citation.cfm?doid=307824.307853 -- Association for Computing Machinery
http://www.amazon.com/dp/B00GX2B8F0 -- eBook on Forth AI thinking in German

[Brian Fox]

> Forth AI coder's note:
> FPGA stands for field-programmable gate array.
>

As that guy in the commercial says: "Thank you captain obvious"

[Hugh Aguilar]

This is not John Hart. This is the spoof email: johnro...@gmail.com
John Hart's email is: jh...@testra.com

My read on the situation is that John Hart has abandoned Testra and the processor
because no customer will ever buy the Testra processor now that Tom Hart has
disgraced himself publicly as a liar. Most likely, John Hart is focusing on his pro-life anti-abortion
hobby-horse. In John Hart's absence, Tom Hart searched through the computer that John Hart left
on his desk looking for the password to the website account so he could hijack John Hart's email.
Fortunately, he didn't find it, so he is still using this fake gmail address. He did find a file related
to the processor that looked important, so he posted it here on comp.lang.forth in the hope
that somebody would explain to him what it means. He is fishing for somebody who will not only
explain to him what this file means, but will also volunteer to work for Testra for free
to complete the 32-bit chip design. Good luck! Nobody is stupid enough to help Tom Hart make money.

BTW: This is described as: "Op Code File for MFX. Generated by MAKE-OPS v13"
This is not actually for MFX though --- I have never seen this file format --- it is not for MFX.
Tom Hart doesn't know what MFX is. He just found this file on John Hart's computer and he assumed
that it must somehow be related to MFX, but it isn't.

[Hugh Aguilar]

> ...

I don't know what data-format this file is in, or what software might use it.
I can make a few observations though.
I don't see anything here that indicates that the opcode has five fields and that
each field is an instruction, with all five instructions executing in parallel
(the opcode taking one clock cycle) as was done on the MiniForth.
I don't think that this new RACE processor running on an FPGA is a VLIW processor
as the MiniForth running on the Lattice isp1048 PLD was. I think that it just
executes instructions sequentially like any traditional processor.

Most likely, this MAKEOPS program (version 13, no less) is a replacement for my DUJOUR.4TH
file that I had back in 1994. Tom Hart (impersonating John Hart) is posting the output from
this MAKEOPS program because he knows that the MAKEOPS program was written after
I left and hence is unfamiliar to me. He is posting this for the purpose of proving that I don't know anything
about MFX and/or that MFX has advanced considerably beyond the humble beginnings that I wrote in 1994.

On this thread: https://groups.google.com/g/comp.lang.forth/c/wydQr643gX0/m/3EctGDucAQAJ
I said this:
On Tuesday, November 9, 2021 at 5:16:05 PM UTC-7, Hugh Aguilar wrote:
> Ilya's technique with multi-core loosely-coupled Forth processors is appropriate
> for FPGAs because they have a lot of resources but they lack connectivity.
> The MiniForth was built on the Lattice isp1048 PLD in 1994 that had very little
> resources but a lot of connectivity --- VLIW was appropriate then.
> Most likely, this is the point that Ilya is trying to make --- VLIW is obsolete now.

Many HDL programmers (Verilog or VHDL) have told me that VLIW can't be done
on an FPGA due to a lack of connectivity. The instructions in each field have different
destination registers, but their source registers are the destination registers of other fields.
This means that registers can be written to (by an instruction in one field) and read from
(by an instruction in another field) concurrently, because both instructions are in the same
opcode and all instructions (up to five) in an opcode execute concurrently (one clock cycle
per opcode). This business of reading and writing registers concurrently means that the
registers have to be hardware (not internal memory of the FPGA), and the registers have to
have a lot of connectivity. This is how a PLD worked back in the 1990s. This is not how
an FPGA works nowadays. Back in the 1990s, PLDs had very little resources (no support
for addition/subtraction, no internal memory, etc.), but they had a lot of connectivity.
Now FPGAs have a lot of resources but not much connectivity. This is why loosely-coupled
parallelism (such as done in Ilya's multi-core processors) is a good fit for FPGAs, but
tightly-coupled parallelism (such as done in the MiniForth) is a bad fit for FPGAs.
Tightly-coupled parallelism might still be a good fit for ASICs, but this isn't going to happen
because ASICs have a huge upfront cost, so this isn't done unless there is already a customer
lined up to purchase the chips in a large volume.

The upshot of all of this, is that Testra's RACE processor is obsolete.
It is a single-core processor with a lot of interrupt latency, but the world has moved on to
multi-core processors (most of which don't use interrupts at all, because each core is dedicated
to pushing data in or out of some I/O port). I'm still proud of having written MFX, but this doesn't
necessarily mean that I think VLIW is a good idea nowadays --- our opportunity was in 1995,
but we blew it --- that opportunity was gone by the turn of the century, which is two decades past now.

My expertise is in VLIW --- that makes me obsolete --- nobody cares about VLIW nowadays.

[Rick C]

On Sunday, November 28, 2021 at 6:05:27 PM UTC-4, Hugh Aguilar wrote:
>
> I don't know what data-format this file is in, or what software might use it.
> I can make a few observations though.
> I don't see anything here that indicates that the opcode has five fields and that
> each field is an instruction, with all five instructions executing in parallel
> (the opcode taking one clock cycle) as was done on the MiniForth.
> I don't think that this new RACE processor running on an FPGA is a VLIW processor
> as the MiniForth running on the Lattice isp1048 PLD was. I think that it just
> executes instructions sequentially like any traditional processor.
>
> Most likely, this MAKEOPS program (version 13, no less) is a replacement for my DUJOUR.4TH
> file that I had back in 1994. Tom Hart (impersonating John Hart) is posting the output from
> this MAKEOPS program because he knows that the MAKEOPS program was written after
> I left and hence is unfamiliar to me. He is posting this for the purpose of proving that I don't know anything
> about MFX and/or that MFX has advanced considerably beyond the humble beginnings that I wrote in 1994.
>
> On this thread: https://groups.google.com/g/comp.lang.forth/c/wydQr643gX0/m/3EctGDucAQAJ
> I said this:
> On Tuesday, November 9, 2021 at 5:16:05 PM UTC-7, Hugh Aguilar wrote:
> > Ilya's technique with multi-core loosely-coupled Forth processors is appropriate
> > for FPGAs because they have a lot of resources but they lack connectivity.

This is pure BS. FPGAs are known for being mostly interconnectivity, otherwise known as routing. In the early days when the FPGA makers understood this and the designers (who were mostly new to this technology) would complain about the issues, the sales people would say they sell you the routing and give you the logic for free meaning the chip is mostly routing.

> > The MiniForth was built on the Lattice isp1048 PLD in 1994 that had very little
> > resources but a lot of connectivity --- VLIW was appropriate then.
> > Most likely, this is the point that Ilya is trying to make --- VLIW is obsolete now.
>
> Many HDL programmers (Verilog or VHDL) have told me that VLIW can't be done
> on an FPGA due to a lack of connectivity.

More BS. Anyone who tells you that doesn't know FPGAs and I seriously doubt any designer who knows FPGAs and understands VLIW would say such a thing.

> The instructions in each field have different
> destination registers, but their source registers are the destination registers of other fields.
> This means that registers can be written to (by an instruction in one field) and read from
> (by an instruction in another field) concurrently, because both instructions are in the same
> opcode and all instructions (up to five) in an opcode execute concurrently (one clock cycle
> per opcode). This business of reading and writing registers concurrently means that the
> registers have to be hardware (not internal memory of the FPGA), and the registers have to
> have a lot of connectivity.

Again, more BS. The registers in an FPGA can be read by many destinations and written on the same clock cycle. When you say "internal memory" do you mean the block RAM (dedicated blocks of memory of 8kbits or larger) or do you include the memory that in many brands of FPGA are the configuration storage for the LUT of which there are MANY! These small memories can be 16x1, 16x2, 32x1 and many other configurations depending on the device. This is what is typically used for register file storage requiring a LUT for each separately addressed read bit. If you need to address different registers from many destinations you can just use FPGA registers as the register files just like external chips, except without the horrendous numbers of I/O pins.

> This is how a PLD worked back in the 1990s. This is not how
> an FPGA works nowadays. Back in the 1990s, PLDs had very little resources (no support
> for addition/subtraction, no internal memory, etc.), but they had a lot of connectivity.
> Now FPGAs have a lot of resources but not much connectivity. This is why loosely-coupled
> parallelism (such as done in Ilya's multi-core processors) is a good fit for FPGAs, but
> tightly-coupled parallelism (such as done in the MiniForth) is a bad fit for FPGAs.
> Tightly-coupled parallelism might still be a good fit for ASICs, but this isn't going to happen
> because ASICs have a huge upfront cost, so this isn't done unless there is already a customer
> lined up to purchase the chips in a large volume.

There is nothing done in the MiniForth processor you have discussed that could not be done completely in an FPGA. Nothing. It would be faster, cheaper and potentially handle a lot more.

> The upshot of all of this, is that Testra's RACE processor is obsolete.
> It is a single-core processor with a lot of interrupt latency, but the world has moved on to
> multi-core processors (most of which don't use interrupts at all, because each core is dedicated
> to pushing data in or out of some I/O port). I'm still proud of having written MFX, but this doesn't
> necessarily mean that I think VLIW is a good idea nowadays --- our opportunity was in 1995,
> but we blew it --- that opportunity was gone by the turn of the century, which is two decades past now.
>
> My expertise is in VLIW --- that makes me obsolete --- nobody cares about VLIW nowadays.

What you call VLIW, if I recall correctly, is what others call microcode. That is also a very good match with FPGAs as they can provide instruction memory of any width you might want. FPGAs are the perfect target for a VLIW. The issue is most people aren't interested in the programming hassles for the limited improvement in processing capabilities. They are able to get the job done with simpler tools and processors.

If anyone identifies an application that would profitably be addressed with a VLIW architecture, I would be happy to oblige with a board and an FPGA design to suit. But these days I don't want to play. I want to make money.

VLIW can be very fast, but you need to be skilled to program it. Hugh sounds like he was once that skilled having written a compiler that targeted a VLIW instruction set, but what are the chances of him ever being lucid enough to repeat the task?

--

Rick C.

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

[Hugh Aguilar]

On Monday, November 29, 2021 at 9:41:48 AM UTC-7, gnuarm.del...@gmail.com wrote:
> On Sunday, November 28, 2021 at 6:05:27 PM UTC-4, Hugh Aguilar wrote:
> > Many HDL programmers (Verilog or VHDL) have told me that VLIW can't be done
> > on an FPGA due to a lack of connectivity.
> More BS. Anyone who tells you that doesn't know FPGAs and I seriously doubt any designer who knows FPGAs
> and understands VLIW would say such a thing.

You have never implemented a VLIW processor.
When you say that you "understand VLIW" you mean that you read a magazine article about it.

> What you call VLIW, if I recall correctly, is what others call microcode.

No. What I call VLIW is what other call VLIW.
This is a processor with multiple instructions per opcode (in distinct fields).
All of the instructions in the opcode execute concurrently, with one clock cycle per opcode.

> If anyone identifies an application that would profitably be addressed with a VLIW architecture, I would be happy to oblige
> with a board and an FPGA design to suit. But these days I don't want to play. I want to make money.

Rick Collins is a scam artist.
He has zero experience with implementing VLIW processors, but he expects people
to pay him to do this job that he has never done before and knows nothing about.

If he tries to implement a VLIW processor in an FPGA, it won't rout.
He says that it will rout. How does he know that??? He has never tried the experiment.
He is substituting wishful-thinking for actual experience --- a typical sales-clown.

It might be possible to use a large expensive FPGA for a small simple VLIW processor, but that is inefficient.
VLIW is a mismatch for FPGA chips' advantages and disadvantages.

> VLIW can be very fast, but you need to be skilled to program it.

Rick Collins is incompetent as a programmer.
Here is a thread in January of 2021 in which he struggles to figure out a way to convert a number
into a hexadecimal string. A search through comp.lang.forth shows that he has been struggling
with this problem since 2015 (or, at least, he has been public about his struggle since 2015).
https://groups.google.com/g/comp.lang.forth/c/vkv3OO4hMTo/m/UsuFK_dWDgAJ
Note that he attacks me, saying that my code doesn't work --- but it does work --- this is easy!

Most likely, Rick Collins' plan in regard to getting a customer who wants a VLIW processor,
is to make the processor execute the instructions in the opcode sequentially in some predetermined order.
So, other than the fact that several instructions get packed into each opcode, reducing the code-memory
usage, this is still just a traditional processor. The BUGS18 is an example of this; it has three 6-bit fields
in each 18-bit opcode (64 Forth words), and the fields execute sequentially. This is not VLIW.
The customer will likely not figure out that he has been scammed. LOL

[Rick C]

On Thursday, December 2, 2021 at 7:31:32 PM UTC-5, Hugh Aguilar wrote:
> On Monday, November 29, 2021 at 9:41:48 AM UTC-7, gnuarm.del...@gmail.com wrote:
> > On Sunday, November 28, 2021 at 6:05:27 PM UTC-4, Hugh Aguilar wrote:
> > > Many HDL programmers (Verilog or VHDL) have told me that VLIW can't be done
> > > on an FPGA due to a lack of connectivity.
> > More BS. Anyone who tells you that doesn't know FPGAs and I seriously doubt any designer who knows FPGAs
> > and understands VLIW would say such a thing.
> You have never implemented a VLIW processor.
> When you say that you "understand VLIW" you mean that you read a magazine article about it.

No, I mean I worked on an attached array processor that used a VLIW, which in those days was called "microcode". To avoid the time of decode, the control points in the machine were each controlled by individual bits in the 100+ bit instruction word.

The machine actually had two programmable units, one to control the computations in the ALU, register file and cache memory and another to move data between main memory and cache. The ALU had five compute units, two adders, two multipliers and a divide/square root unit (I think the divide square root unit usurped a multiplier when used). Each could operate independently in parallel with separate instruction fields in the "opcode" on data fetched from the register file with 8 reads and four writes operating in parallel. That seems to fit your definition of VLIW.

I don't think VLIW was a thing at the time this was designed. Wikipedia talks about the term being coined in the 1980's when this array processor was already being shipped.

> > What you call VLIW, if I recall correctly, is what others call microcode.
> No. What I call VLIW is what other call VLIW.
> This is a processor with multiple instructions per opcode (in distinct fields).

That is the way TI designed the TMS6xxx line of processors, with eight 32 bit instructions per "opcode".

> All of the instructions in the opcode execute concurrently, with one clock cycle per opcode.

Yup, that's the way the array processor worked.

> > If anyone identifies an application that would profitably be addressed with a VLIW architecture, I would be happy to oblige
> > with a board and an FPGA design to suit. But these days I don't want to play. I want to make money.
> Rick Collins is a scam artist.
> He has zero experience with implementing VLIW processors, but he expects people
> to pay him to do this job that he has never done before and knows nothing about.

All my life I have done things I've never done before and knew little about until I did them. That's because I'm capable of learning. It's an amazing skill. It has served me well.

> If he tries to implement a VLIW processor in an FPGA, it won't rout.
> He says that it will rout. How does he know that??? He has never tried the experiment.
> He is substituting wishful-thinking for actual experience --- a typical sales-clown.

You mean I have done many, many FPGA designs and actually know something about them while you literally know nothing other than what you may have read in a magazine article or been misinformed about by someone who knows no more than you.

These days there is very little you can't do in an FPGA. The idea of a design not routing being a limitation means you don't understand FPGAs. If it doesn't route, use a larger FPGA with more routing! Anyone who knows the basics of FPGAs understands that.

> It might be possible to use a large expensive FPGA for a small simple VLIW processor, but that is inefficient.
> VLIW is a mismatch for FPGA chips' advantages and disadvantages.

If it's a small, simple design it will route in a small FPGA. But you don't even understand connectivity in electronic designs, so I don't expect you to understand that.

> > VLIW can be very fast, but you need to be skilled to program it.
> Rick Collins is incompetent as a programmer.
> Here is a thread in January of 2021 in which he struggles to figure out a way to convert a number
> into a hexadecimal string. A search through comp.lang.forth shows that he has been struggling
> with this problem since 2015 (or, at least, he has been public about his struggle since 2015).
> https://groups.google.com/g/comp.lang.forth/c/vkv3OO4hMTo/m/UsuFK_dWDgAJ
> Note that he attacks me, saying that my code doesn't work --- but it does work --- this is easy!

You are funny. I seem to recall a programming problem that you had completely wrong, I provided a correct answer to and you refused to acknowledge it. Everyone in the group told you that you were wrong and I was right, but you just couldn't accept that. I suppose now you are going to melt down and explode like a TV robot confronted with a self contradiction.

> Most likely, Rick Collins' plan in regard to getting a customer who wants a VLIW processor,
> is to make the processor execute the instructions in the opcode sequentially in some predetermined order.

Why are you so dense? It's easy in an FPGA. Just have multiple compute units and assign a separate instruction field for each one. This is not rocket science.

> So, other than the fact that several instructions get packed into each opcode, reducing the code-memory
> usage, this is still just a traditional processor. The BUGS18 is an example of this; it has three 6-bit fields
> in each 18-bit opcode (64 Forth words), and the fields execute sequentially. This is not VLIW.
> The customer will likely not figure out that he has been scammed. LOL

Wow! Do you ever do anything useful? Or are you just so lost in the ozone you are incapable of doing useful work at all these days?

I also was peripherally connected with a Navy project to design a common platform signal processor that could have been implemented on the array processor I worked with. What they wanted was a common programming environment that was data directed and graphical. But for who knows what reason they insisted on designing hardware to run it on. The hardware needed to be tailored to the various application environments which ended up killing the hardware project and the software project went down with it too. The architecture of the hardware was vaguely similar to the array processor I worked on, but was more closely tied to the software architecture. This was actually a liability because it had to be custom at a time when commercial hardware was starting to lead anything military by leaps and bounds. Too expensive, too slow and too late - the project died. Had they stuck with data flow in the software design process, compiling to a VLIW array processor, they could have used commercial hardware that got faster and faster every year. They do this a lot now.

Oh well...

--

Rick C.

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

[Hugh Aguilar]

On Friday, December 3, 2021 at 12:34:59 AM UTC-7, gnuarm.del...@gmail.com wrote:
> On Thursday, December 2, 2021 at 7:31:32 PM UTC-5, Hugh Aguilar wrote:
> > > VLIW can be very fast, but you need to be skilled to program it.
> > Rick Collins is incompetent as a programmer.
> > Here is a thread in January of 2021 in which he struggles to figure out a way to convert a number
> > into a hexadecimal string. A search through comp.lang.forth shows that he has been struggling
> > with this problem since 2015 (or, at least, he has been public about his struggle since 2015).
> > https://groups.google.com/g/comp.lang.forth/c/vkv3OO4hMTo/m/UsuFK_dWDgAJ
> > Note that he attacks me, saying that my code doesn't work --- but it does work --- this is easy!
> You are funny. I seem to recall a programming problem that you had completely wrong,
> I provided a correct answer to and you refused to acknowledge it. Everyone in the group told you that you were wrong
> and I was right, but you just couldn't accept that. I suppose now you are going to melt down and explode
> like a TV robot confronted with a self contradiction.

This is from that thread:

On Thursday, January 21, 2021 at 2:18:20 AM UTC-7, gnuarm.del...@gmail.com wrote:
> On Thursday, January 21, 2021 at 3:15:35 AM UTC-5, dxforth wrote:
> > On 21/01/2021 00:24, NN wrote:
> > > On Wednesday, 20 January 2021 at 08:43:21 UTC, Alexander Wegel wrote:
> > >> Hugh Aguilar <hughag...@gmail.com> wrote:
> > >>
> > >> > It is not really that I (Hugh Aguilar, slammed by Bernd Payson for being
> > >> > unwise) don't know how to use a flag as a mask in logic-arithmetic --- it
> > >> > is just that I don't want to --- this is my own code (written in ANS-Forth,
> > >> > and one of the previous versions mentioned above as not being acceptable):
> > >> >
> > >> > : indexed-char \ index adr cnt -- char
> > >> > \ the string will be used as an array of chars
> > >> > rover 0< abort" *** INDEXED-CHAR given a negative index ***"
> > >> > rover <= abort" *** INDEXED-CHAR given an index too large ***"
> > >> > + c@ ;
> > >> >
> > >> > : hexit>char \ [0,15] -- char
> > >> > s" 0123456789ABCDEF" indexed-char ;
> > >> >
> > >> > This is an example of how I relate to Forth differently from most ANS-Forth
> > >> > and Forth-200x enthusiasts
> > >> It's inefficient, doing a lot of superfluous checking and juggling. As
> > >> Hugh Aguilar would say: "you screwed it up".
> > >
> > >
> > > Therein lies the problem ....
> > >
> > > the question should really be is the function giving the correct output in the
> > > environment its being used ?
> > >
> > > What you might consider inefficient for your use , might be perfectable for
> > > someone else.
> > >
> > > The programmer can always come back at a later stage and rewrite it should
> > > the need arise.
> > >
> > > So was the function correct ?
> > >
> > I can imagine an ascii to binary routine potentially requiring checks,
> > but not the reverse.
> Sure, the way this routine is written anything outside the range of 0-15 will cause an access outside the declared array resulting in an ambiguous condition. Either flag the error or the bits of interest should be masked off first to preclude the error. As written the calling routine would need to do the masking.
>
> --
>
> Rick C.

Here is the thread from 2015 in which Rick Collins first began struggling with
the problem of converting numbers into hex chars. In this thread Elizabeth Rather
praises as having "proper documentation" making it "readable and maintainable"
whereas she slams my code as being "unacceptable."
Note that Bernd Paysan is slamming me for not being wise and not being capable
of learning about masks and logical operations. This insult was prior to
me getting into this thread --- I had not yet entered the thread because
it seemed too trivial to bother with --- Bernd Paysan just insults me gratuitously
as a way of reminding everybody that he is supporting Elizabeth Rather and hence
has her full support. This is why he is on the Forth-200x committee!

We had this example of using a flag as a mask was given by Rick Collins
(modified slightly here to make it ANS-Forth):

: >CHAR ( [0,15] -- char )
DUP 9 > 7 AND + [CHAR] 0 + ;

A Forther (Hans Bezemer) complained that this code is bad style,
and the Forth-200x committee-member Bernd Payson defended it:

On Sunday, May 24, 2015 at 5:21:05 PM UTC-7, Bernd Paysan wrote:
> Hans Bezemer wrote:
> > ...True, it
> > is a clever piece of programming, but in our opinion it is bad
> > style. Why? Because you are using a flag as a bitmask, which is a
> > completely different datatype. Although there is no such thing as
> > “data typing” in Forth, this way of programming makes it
> > difficult to understand and maintain a program, which the
> > ANS-Forth standard acknowledges:
>
> Honestly, this is only a problem if you don't know that idiom. A lot of
> people don't know that you can use masks and logical operations, so they
> will find that operation strange.
> ...
> Therefore, I would reiterate what I told Hugh some times: If you don't know
> something, it's *not* the fault of the person who uses and knows that thing.
> It's entirely your fault, and if you want to be a wise person, you'd rather
> learn it that complain.
>
> IMHO the whole datatype based thinking about cells in Forth is ill-advised.
> First, and foremost, a cell is a bit pattern, and if you add and subtract
> it, it's a mod 2^n ring. You can use that to some degrees as integer, but
> it's not an integer. It's a cell.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"

Elizabeth Rather responded:

> Thank, you, Bernd, well-said.
>
> Cheers,
> Elizabeth

A little later we had this:

On Tuesday, May 26, 2015 at 11:37:37 AM UTC-7, Elizabeth D. Rather wrote:
> On 5/26/15 8:15 AM, rickman wrote:
> > On 5/26/2015 1:20 PM, WJ wrote:
> >> That code is unreadable and unmaintainable. It's very hard
> >> to figure out how it accomplishes its task. I would not
> >> pay a programmer to produce code like that.
> >>
> >> This is somewhat more understandable:
> >>
> >> : >char
> >> dup 9 > if [char] A 10 - else [char] 0 then
> >> + ;
> >
> > If you have any reason to look at the definition of >char then I can't
> > see how you would not understand how it works. Perhaps this would be a
> > better definition...
> >
> > \ Convert n to ASCII char
> > : >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ;
> >
> > Lol, saying it is unreadable and unmaintainable is a bit of a stretch. I
> > think that exact code has been read and understood as well as maintained
> > for many years now. I am pretty sure I have seen something similar to
> > it way back when I was learning assembly language. I think it took me
> > two minutes to see what it was doing.
>
> Indeed, proper documentation as in rickman's version above is essential
> to readable & maintainable code. Neither of the previous versions is
> acceptable, although I find the shorter code quite clear (and, as
> rickman notes, it's been around for many years). I would have preferred
> [CHAR] instead of ASCII, however, as it's Standard.
>
> Cheers,
> Elizabeth

[dxforth]

On 4/12/2021 16:07, Hugh Aguilar wrote:
> ...

> We had this example of using a flag as a mask was given by Rick Collins
> (modified slightly here to make it ANS-Forth):
>
> : >CHAR ( [0,15] -- char )
> DUP 9 > 7 AND + [CHAR] 0 + ;
>
> A Forther (Hans Bezemer) complained that this code is bad style,
> and the Forth-200x committee-member Bernd Payson defended it

As would I given it was classical and the suggested alternatives
weren't unequivocally better (unlike my READ-LINE spec :)

: >CHAR ( [0,15] -- char )
DUP 9 > 7 AND + [CHAR] 0 + ;

see >char
>CHAR
( 004F0890 83FB09 ) CMP EBX, 09
( 004F0893 0F9FC2 ) SETNLE/G DL
( 004F0896 F6DA ) NEG DL
( 004F0898 0FBED2 ) MOVSX EDX, DL
( 004F089B 83E207 ) AND EDX, 07
( 004F089E 03DA ) ADD EBX, EDX
( 004F08A0 83C330 ) ADD EBX, 30
( 004F08A3 C3 ) NEXT,
( 20 bytes, 8 instructions )

: hexit>char \ [0,15] -- char

s" 0123456789ABCDEF" drop + c@ ;

see hexit>char
HEXIT>CHAR
( 004F08D0 E8AB19F2FF ) CALL 00412280 (S") "0123456789ABCDEF"
( 004F08E8 8B5D00 ) MOV EBX, [EBP]
( 004F08EB 035D04 ) ADD EBX, [EBP+04]
( 004F08EE 8D6D08 ) LEA EBP, [EBP+08]
( 004F08F1 E806A0F1FF ) CALL 0040A8FC C@
( 004F08F6 C3 ) NEXT,
( 39 bytes, 6 instructions )

[Nickolay Kolchin]

Well, at least first variant doesn't segfault on invalid input...

Btw, lxf generates much better assembler:

: T1 DUP 9 > 7 AND + [CHAR] 0 + ;
: T2 S" 0123456789ABCDEF" DROP + C@ ;

see t1
8691F10 804FBE4 20 88C8000 5 normal T1

804FBE4 83FB09 cmp ebx , # 9h
804FBE7 0F9FC0 setg al
804FBEA 0FBEC0 movsx eax , al
804FBED F7D8 neg eax
804FBEF 83E007 and eax , # 7h
804FBF2 01C3 add ebx , eax
804FBF4 83C330 add ebx , # 30h
804FBF7 C3 ret near
ok
see t2
8691F24 804FBF8 10 88C8000 5 normal T2

804FBF8 81C3F89C3808 add ebx , # 8389CF8h
804FBFE 0FB61B movzx ebx , byte ptr [ebx]
804FC01 C3 ret near
ok

[dxforth]

On 4/12/2021 18:06, Nickolay Kolchin wrote:
> ...

> Well, at least first variant doesn't segfault on invalid input...

The second included a test but was removed for comparison.

>
> Btw, lxf generates much better assembler:

Still longer factoring in the string. OTOH should now be faster than
the others. On VFX (in-lined string) it ran 10x slower than first
variant, so no gain at all.

[Rick C]

On Saturday, December 4, 2021 at 12:07:07 AM UTC-5, Hugh Aguilar wrote:
> On Friday, December 3, 2021 at 12:34:59 AM UTC-7, gnuarm.del...@gmail.com wrote:
> > On Thursday, December 2, 2021 at 7:31:32 PM UTC-5, Hugh Aguilar wrote:
> > > > VLIW can be very fast, but you need to be skilled to program it.
> > > Rick Collins is incompetent as a programmer.
> > > Here is a thread in January of 2021 in which he struggles to figure out a way to convert a number
> > > into a hexadecimal string. A search through comp.lang.forth shows that he has been struggling
> > > with this problem since 2015 (or, at least, he has been public about his struggle since 2015).
> > > https://groups.google.com/g/comp.lang.forth/c/vkv3OO4hMTo/m/UsuFK_dWDgAJ
> > > Note that he attacks me, saying that my code doesn't work --- but it does work --- this is easy!
> > You are funny. I seem to recall a programming problem that you had completely wrong,
> > I provided a correct answer to and you refused to acknowledge it. Everyone in the group told you that you were wrong
> > and I was right, but you just couldn't accept that. I suppose now you are going to melt down and explode
> > like a TV robot confronted with a self contradiction.
> This is from that thread:

<<< pointless example snipped >>>

I don't think that was the example I was thinking about. It was something different that you probably put out of your mind because you literally attacked my version and posted your own which didn't actually work over the full range of valid input. I don't recall the function, it may have been a log conversion.

I'm sure you will not be able to rest until you find it which is not my goal. I simply wish to point out that while you love to criticize others for their imperfect code making them "incompetent" programmers, you have fails of your own. So does that make YOU an incompetent programmer? No. It makes you human. Why don't you accept that we are all human and treat the rest of us as you would like to be treated?

Meanwhile, we seem to have stopped talking about VLIW being a good match for FPGAs.

--

Rick C.

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

[Marcel Hendrix]

On Saturday, December 4, 2021 at 8:06:47 AM UTC+1, Nickolay Kolchin wrote:
> On Saturday, December 4, 2021 at 9:25:45 AM UTC+3, dxforth wrote:

[..]

> Well, at least first variant doesn't segfault on invalid input...
>
> Btw, lxf generates much better assembler:
>
> : T1 DUP 9 > 7 AND + [CHAR] 0 + ;
> : T2 S" 0123456789ABCDEF" DROP + C@ ;
>
> see t1
> 8691F10 804FBE4 20 88C8000 5 normal T1
>
> 804FBE4 83FB09 cmp ebx , # 9h
> 804FBE7 0F9FC0 setg al
> 804FBEA 0FBEC0 movsx eax , al
> 804FBED F7D8 neg eax
> 804FBEF 83E007 and eax , # 7h
> 804FBF2 01C3 add ebx , eax
> 804FBF4 83C330 add ebx , # 30h
> 804FBF7 C3 ret near
> ok
> see t2
> 8691F24 804FBF8 10 88C8000 5 normal T2
>
> 804FBF8 81C3F89C3808 add ebx , # 8389CF8h
> 804FBFE 0FB61B movzx ebx , byte ptr [ebx]
> 804FC01 C3 ret near
> ok

iForth64:
FORTH> : T1 DUP 9 > 7 AND + [CHAR] 0 + ; ok
FORTH> : T2 S" 0123456789ABCDEF" DROP + C@ ; ok
FORTH> ' t1 idis
$0133D700 : T1
$0133D70A pop rbx
$0133D70B cmp rbx, 9 b#
$0133D70F setg cl
$0133D713 movzx rcx, cl
$0133D717 neg rcx
$0133D71A and rcx, 7 b#
$0133D71E lea rbx, [rbx rcx*1 #48 +] qword
$0133D723 push rbx
$0133D724 ; ok
FORTH> see t2
Flags: ANSI
$0133D780 : T2
$0133D78A pop rbx
$0133D78B movzx rdi, [rbx $0132CF88 +] byte
$0133D793 push rdi
$0133D794 ;

-marcel

[Nickolay Kolchin]

You are the only one that was able to combine BX operations in single LEA!

[Hugh Aguilar]

On Friday, December 3, 2021 at 12:34:59 AM UTC-7, gnuarm.del...@gmail.com wrote:
> On Thursday, December 2, 2021 at 7:31:32 PM UTC-5, Hugh Aguilar wrote:
> > On Monday, November 29, 2021 at 9:41:48 AM UTC-7, gnuarm.del...@gmail.com wrote:
> > > If anyone identifies an application that would profitably be addressed with a VLIW architecture,
> > > I would be happy to oblige
> > > with a board and an FPGA design to suit. But these days I don't want to play. I want to make money.
> > Rick Collins is a scam artist.
> > He has zero experience with implementing VLIW processors, but he expects people
> > to pay him to do this job that he has never done before and knows nothing about.
> All my life I have done things I've never done before and knew little about until I did them.
> That's because I'm capable of learning. It's an amazing skill. It has served me well.

This is the year 2021 and Rick Collin's "amazing skill" of learning has not yet been put to use
to allow him to learn how integer addition works in computers:

On Saturday, December 11, 2021 at 2:29:36 PM UTC-7, gnuarm.del...@gmail.com wrote:
> On Saturday, December 11, 2021 at 3:51:59 PM UTC-5, Hugh Aguilar wrote:
> > I considered MFX assembly-language to be fun. :-)
> > My idea of fun doesn't necessarily correspond to most people's idea of fun.
> > The only addressing-mode supported was inherent --- none of the instructions had operands.
> > There was no way to change the control-flow except with the NXT instruction.
> > There was no instruction to do 16-bit integer addition --- this required a pretty complicated function.
> > This was a "serious hardware project" though --- it was used in laser-etching machines.
> > The days of being able to build your own processor that competes with mainstream processors
> > is past. :-( In 1994, the competition was using an MC68000 programmed in C, but the
> > MiniForth built on a Lattice isp1048 PLD and an 8032 was higher performing and less expensive.
> > Nowadays pretty much everybody uses the ARM Cortex for motion-control, programmed in C.
> > Somebody like Nickolay Kolchin would get hired for that --- I would not --- my experience is too
> > esoteric and obsolete, plus Tom Hart refuses to admit that I wrote MFX anyway.

> You say it doesn't have "16-bit integer addition", so what does it have? How is addition done?

Rick Collins wants customers to pay him to implement a VLIW processor,
but he has no experience with implementing a VLIW processor. Here he is expecting
me to explain to him how 16-bit integer addition is implemented in software.

I didn't know how 16-bit integer addition could be done either, back in 1994.
Steve Brault wrote the + primitive. This is the only general-purpose code in MFX
that I didn't write. I would have figured it out though. I just had a lot of other
programming to do, so I hadn't gotten around to delving into that yet.
That was in 1994 --- now I have seen how 16-bit integer addition is implemented
so now I know --- I'm not going to teach Rick Collins how processors work internally.

[Rick C]

Ok, so Hugh is being cryptic as usual. What exactly does the machine do other than a 16 bit add? I can only assume that you are talking about the machine being somehow limited and since I know nothing of this arcane architecture from another century (or nearly so at least) I have no idea what that limitation is. Does it have an 8 bit add? Does it have a 1 bit add? Is it necessary to implement an addition through logic operations? That would certainly be tedious.

I don't expect a real answer from you as you are too far gone to actually discuss anything. But on the off chance you might tell us what you are talking about, I'm willing to listen. I would add that I certainly don't need you to teach me anything about implementing arithmetic operations in hardware. I seem to recall you were a bit confused about the fast carry chain implementation in FPGAs. Certainly you know nothing of routing in FPGAs.

So why not put down your boxing gloves and discuss the add function you are being so cryptic about. What is this limitation you are talking about. What instructions does the CPU have to implement adds with that is not a 16 bit integer add? Or are you talking about the hardware logic?

--

Rick C.

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

[Hugh Aguilar]

You don't know how addition works. You're a fake expert --- you don't really know anything.

> I don't expect a real answer from you as you are too far gone to actually discuss anything.

I'm tired of you endlessly flinging these insults at me
I want you to just piss off --- shining a spotlight on your gross ignorance of basic
concepts such as how integer addition works will hopefully just make you go away.

> But on the off chance you might tell us what you are talking about, I'm willing to listen.

> I would add that I certainly don't need you to teach me anything about implementing arithmetic...

I'm not willing to teach you basic concepts such as how integer addition works.
PISS OFF! FAKE EXPERT!

[Rick C]

I think it is you who is the fake. You claim I know nothing and yet are unwilling to show that by demonstration. You probably don't even understand what I wrote.

> > I don't expect a real answer from you as you are too far gone to actually discuss anything.
> I'm tired of you endlessly flinging these insults at me

That's not as much an insult as a simple statement of fact. As I said, I don't expect anything from you other than a tirade and you have responded exactly in that way. Silly of me to act as if there was any chance of anything different. Maybe I'm the one who is insane because I would appear to have some expectation you might engage in a technical discussion rather than a rant.

> I want you to just piss off --- shining a spotlight on your gross ignorance of basic
> concepts such as how integer addition works will hopefully just make you go away.

So far you've only shown the spotlight on your own ignorance. You don't even know what the MFX addition primitive is.

> > But on the off chance you might tell us what you are talking about, I'm willing to listen.
> > I would add that I certainly don't need you to teach me anything about implementing arithmetic...
>
> I'm not willing to teach you basic concepts such as how integer addition works.
> PISS OFF! FAKE EXPERT!

Sure, I'll stop when you do.

--

Rick C.

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

[John Hart]

<clip>

> > > >
> > > > > You say it doesn't have "16-bit integer addition", so what does it have? How is addition done?
> > > >

<clip>
The PLD for our first reconfigurable processor didn't support arithmetic functions, so addition was done in
two steps. First, the 16bit numbers were XORed, then the carry was propagated 4bits at a time, so it took
5 cycles to do an add. We moved the design to the FPGA without changing the architecture but added a
second set of registers for a virtual core that ran an i/o process that used to run on an 8032.
The new design is 32bit, and looking back it would have been better to have moved directly to it, but
I had't finished our Forth FPGA design tools at that time. Translating Forth to logic for the PLD was easy
but the method didn't work well for FPGA's. The PLD logic cells had 18 inputs, LUTs have 4 or 5.

[Rick C]

XORing the two addends will give the sum of each bit position of addends, but how exactly did you calculate the 4 bits of carry? Was there a special instruction for that? The individual bit position carry is just an AND of the two input bits, but gets a bit more complex if including the carry in as does the SUM which is the XOR of all three inputs at that point.

BTW, who are you? In Google groups you only show up as " johnro...@gmail.com"...

--

Rick C.

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

[John Hart]

On Wednesday, December 15, 2021 at 10:31:31 PM UTC-7, gnuarm.del...@gmail.com wrote:
> On Wednesday, December 15, 2021 at 8:57:46 PM UTC-4, johnro...@gmail.com wrote:
> > <clip>
> > > > > >
> > > > > > > You say it doesn't have "16-bit integer addition", so what does it have? How is addition done?
> > > > > >
> > <clip>
> > The PLD for our first reconfigurable processor didn't support arithmetic functions, so addition was done in
> > two steps. First, the 16bit numbers were XORed, then the carry was propagated 4bits at a time, so it took
> > 5 cycles to do an add. We moved the design to the FPGA without changing the architecture but added a
> > second set of registers for a virtual core that ran an i/o process that used to run on an 8032.
> > The new design is 32bit, and looking back it would have been better to have moved directly to it, but
> > I had't finished our Forth FPGA design tools at that time. Translating Forth to logic for the PLD was easy
> > but the method didn't work well for FPGA's. The PLD logic cells had 18 inputs, LUTs have 4 or 5.

> XORing the two addends will give the sum of each bit position of addends, but how exactly did you calculate the 4 bits of carry? Was there a special instruction for that? The individual bit position carry is just an AND of the two input bits, but gets a bit more complex if including the carry in as does the SUM which is the XOR of all three inputs at that point.
>

AC TR XOR -> AX

01 ]: AC TR XOR >>O AC ;[ MAP \ AC_XOR_TR>AC

10 ]: AC AX TR - CRY- 10000 * OR 10 U/ >>O AC ;[ MAP \ AC-TR-CRY>>AC
11 ]: AC AX TR + CRY+ 10000 * OR 10 U/ >>O AC ;[ MAP \ AC+TR+CRY>>AC
12 ]: AC AC CRY- 10000 * OR 10 U/ >>O AC ;[ MAP \ AC-CRY>>AC
13 ]: AC AC CRY+ 10000 * OR 10 U/ >>O AC ;[ MAP \ AC+CRY>>AC

John H

[Rick C]

Hmmm... I don't know your terminology, but I assume the two addends start in AC and TR which are then XORed with the result in AX. I don't follow the remainder of this at all. Is each line an instruction? I assume the numbers are all binary, so 10000 * is a shift left by 4 bits? Should I assume the shift is performed on the result of the previous operation?

What exactly happens with AC AX TR - CRY-? Is TR a destination? What does CRY- do? If you don't have an addition or subtraction operator, what do '+' and '-' do?

Ah, AC AX TR is simply loading operands onto the stack and - operates on the top two? 10000 * operates on the ToS. I assume the OR operates on the top two elements on the stack and 10 U/ right shifts ToS by one bit. Not following what >>0 AC does.

--

Rick C.

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

[Hugh Aguilar]

On Wednesday, December 15, 2021 at 5:57:46 PM UTC-7, johnro...@gmail.com wrote:
> Translating Forth to logic for the PLD was easy...

I can't imagine John Hart saying that his software to program the Lattice isp1048 PLD
was "easy" --- I recall that he was very proud of this accomplishment --- I also recall
that getting the MiniForth to rout was difficult and required some luck (routing is an
intractable problem, so luck is a major factor in whether or not a design works).
I think this is Tom Hart impersonating John Hart --- I recall that Tom Hart got a thrill
out of belittling other people's accomplishments.

After I wrote MFX, Tom Hart told me that the only reason why I was employed
at Testra was that I worked for cheap. He was essentially say that writing MFX
was easy enough to have been done by anybody, so the only criteria was getting it
done as cheaply as possible, and he would never give me a raise. After I quit and used
Testra as a job reference, he said that I had accomplished nothing and that
I was not eligible for rehire --- this was because his only criteria for an employee
was loyalty. I have no doubt that at the same time he was telling the customers
that writing MFX was easy given his awesome programming ability.

Tom Hart is a fool. He thinks that when he belittles other people's accomplishments
he is impressing the spectators with his technical superiority that he can look down
at any programming task and declare it to be easy. This is foolish because he is declaring
Testra accomplishments to have been easy, so the potential customers think:
"If this product was trivial to build, then why should we pay for it? If it was so easy
that anybody could do it, then it should be given away for free --- we are only willing
to pay for professional work that was not easy to do and hence costs a lot of money."

Tom Hart is an arrogant jack-ass --- this is why Testra was never able to keep any
employees and hence was never able to grow beyond being a small rinky-dink operation.
I am not to blame for Testra remaining small for a quarter of a century --- I wrote MFX,
when nobody else at Testra knew how to do out-of-ordering of instructions which is
required for a VLIW processor --- if I had not gotten MFX to work, Testra would have
likely gone out of business in 1995, but nobody at Testra thanked me for pulling
their bacon out of the fire and instead I got only scorn for being a mere programmer.

[John Hart]

On Thursday, November 25, 2021 at 2:39:20 AM UTC-7, jpit...@gmail.com wrote:

> On Thursday, 25 November 2021 at 07:06:47 UTC, johnro...@gmail.com wrote:
> > \ Op Code File for MFX. Generated by MAKE-OPS v13

> Thank you very much John - let's see what happens next.
> Just for the fun of it I formatted it slightly in a way that makes the blocks a bit clearer to me
> https://www.dropbox.com/sh/ah8umk0hgq1818s/AAC8nNEueZZcIYJ8uGP4F4wPa?dl=0

I've got the next part working and am planning on posting the output,
a 'forth' file that defines control logic decoding. It's derived from the same
set of sets that defined the compiler op codes.
Is there a way for the post to be formated,
I'm using google groups to access the forum and it doesn't provide much.

jrh

[Jurgen Pitaske]

As a start you could send it to my email address epld...@aol.com and I will add it to the dropbox files where the other one is.

[John Hart]

On Wednesday, January 12, 2022 at 3:35:17 AM UTC-7, jpit...@gmail.com wrote:
> On Wednesday, 12 January 2022 at 08:01:17 UTC, johnro...@gmail.com wrote:
> > On Thursday, November 25, 2021 at 2:39:20 AM UTC-7, jpit...@gmail.com wrote:
> > > On Thursday, 25 November 2021 at 07:06:47 UTC, johnro...@gmail.com wrote:
> > > > \ Op Code File for MFX. Generated by MAKE-OPS v13

The Logic Compiler is working and the modules for the processor are done and tested. After the mem interface module is complete we'll be ready to put the design into the fpga. We're using a X02-7000 but the design will work in any equivalent part.
jrh

[Jurgen Pitaske]

Looking forward to it.
Posting and distributing it in different places including facembbok should be easy.

An idea crossed my mind:
Why not do a presentation during a FIG Zoom?
And this would help with where to post it.
http://www.forth.org/svfig/

[Jurgen Pitaske]

Just for people who might not know the context:

Would it not be nice to use VHDL on an FPGA to write to it directly in Forth.
See the link to Testra where it has been done already.
http://testra.com/Forth/VHDL.htm

And hopefully there is more soon from Testra posted here..

[Lorem Ipsum]

Sorry, I don't follow. What are you describing by, "use VHDL on an FPGA to write to it directly in Forth"?

If you are talking about a stack CPU, written in VHDL, running on an FPGA, that has been done many, many times, some published, many not published. It would seem to be a trivial exercise.

--

Rick C.

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

[Jurgen Pitaske]

You are proving again that you attention span is zero - or is it your reading capability?

Designing logic with the Forth VHDL

1. Write a software simulation of the design.
2. Test the design.
3. Convert the software simulation into a hardware definition.
4. Compile the hardware definition into logic equations.
5. Fit the logic equations into the device.
6. Verify that the logic equations work correctly.
7. Route the signals and assign the I/O pins.
8. Convert the routed design into a fusemap.

[none albert]

In article <990840c6-b5e9-4cf1...@googlegroups.com>,

Are you the John Hart made famous by Hugh Aguilar?
Welcome to c.l.f, whatever that is the case!

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Lorem Ipsum]

"Forth VHDL"??? You are talking about a VHDL synthesis tool written in Forth??? No, that doesn't fit the description of what is going on. In fact, your description doesn't seem to relate to VHDL at all.

I can't tell what you are talking about from this description, but it sounds like it is for CPLDs, rather than FPGAs. Maybe we are hitting a language barrier.

--

Rick C.

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

[Jurgen Pitaske]

The linfo at Testra clearly states:

Using Forth as a VHDL ( Virtual Hardware Definition Language )
John R. Hart, Testra Corporation

They used it on a CPLD first, and on a Lattice FPGA 7k now.
Hugh Aguilar was involved there.

And with all of the knowledge and experience here or elsewhere
it could probably be ported to
other FPGA families.

You have all of the advantages of Forth,
and no need for the overhead of FPGA tools as I understand.

I am surprised this has not been of interest for the last many years,
as the info on the Testra website was always there.

But now we hopefully get the opportunity to see a full example.

[Jurgen Pitaske]

Any language can probably be used, not just Forth - see C to HDL
https://en.wikipedia.org/wiki/C_to_HDL
I actually met Ian Page when he was part of our customer Celoxica, then ESL.

Reminded me of an article I wrote probably 20 years ago
https://www.design-reuse.com/articles/7656/fast-route-from-system-specification-to-implementation.html

I would love to this Minimum RISC as example for this Forth to Gates route
https://homepage.cs.uiowa.edu/~jones/arch/risc/
I could convince Steve Teal to write it in VHDL.
And he adapted an eForth to it.
But having the Minimum RISC written in Forth as VHDL would be even more interesting.

[Lorem Ipsum]

Ah, so he's bastardizing the term VHDL. That's normally used as the name of a language for programming digital logic (VHSIC Hardware Description Language).

> They used it on a CPLD first, and on a Lattice FPGA 7k now.
> Hugh Aguilar was involved there.
>
> And with all of the knowledge and experience here or elsewhere
> it could probably be ported to
> other FPGA families.
>
> You have all of the advantages of Forth,
> and no need for the overhead of FPGA tools as I understand.

It's not quite that simple. To target an FPGA device, you have to know the bitstream format. The vendors don't typically provide that information. Some people have reverse engineered a very few of the Lattice parts. I was not aware that the X02-7000 had been reverse engineered, but it's possible. Figuring out the bit map for other devices is not at all simple. It's tons of work.

> I am surprised this has not been of interest for the last many years,
> as the info on the Testra website was always there.

Open source tools have been of interest and exist. But not for many parts, for the reasons I've explained.

> But now we hopefully get the opportunity to see a full example.

"Full example"???

It's a tool of little value in the FPGA world. Homebrew amateurs may find it interesting, but the FPGA world will simply yawn.

I don't know how accurate your list of steps in using the tool is, but it sounds to me like a lot more work than the use of typical FPGA tools. Here's the steps required for designing FPGAs.

1. Write the design in VHDL or Verilog
2. Write a test bench for the simulation stimulus and error checking.
3. Simulate the design using conventional simulators.
4. Synthesize the design for the target chip.
5. Test on the target board.

Done. The only "writing" of code is the design and the test bench for simulation. Everything else is a working tool.

--

Rick C.

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

[Jurgen Pitaske]

I am sorry, but your post does not make sense to me.

Testra use this setup for many years in their products
and it must make sense there,
otherwise they would just use the standard Lattice tools.

If it is not relevant to you - fine - I never asked you.
Just like asking an experienced C programmer - why not Forth ...

[Lorem Ipsum]

LOL Yes, if one guy working in a corner of the room is using it, then it must be not only good, but GREAT!

The millions of users of VHDL and Verilog must have it wrong.

One of my early jobs involved designing a microprogrammed DMA controller using an off the shelf sequencer chip. The other, similar designs in the company all used the same assembler tool. I added a few macros and opcodes, in order to give my design additional self-test capabilities. One of the managers said that was a bad idea because no one else would know how to use this "different" tool. I realized that there are many times when standardization is preferred over technical advantages, because technical advantages are of no use if they make the design hard to work with or modify.

In this case, there is no real utility to this "special" design process and it actually appears to be much more complex and difficult to use.

Thank you for the information.

--

Rick C.

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

[Jurgen Pitaske]

It seems there are others working in the corner that are interested in this subject,
see about 46.00 onwards, e.g. gelforth
https://www.youtube.com/watch?v=ASgBoKisWac

[Lorem Ipsum]

"Others"??? You mean "other", I think.

Trying to use Forth as the language to compose logic is solving a problem that doesn't exist. We have Verilog and VHDL as the mainstream languages for logic hardware design and they work well. There are efforts to use C for hardware logic design, which is seldom used. The main justification for using C is to have a common language for hardware and software, so the dividing line is easily moved, allowing one system design to be implemented in different ways with different performance levels. In reality, this is not at all simple to do. Hardware and software require interfaces. When you change the dividing line in the code for that interface and you have to redesign everything about that interface. So it is seldom used this way.

I stand by my statement that using Forth for both software and hardware design is of little value. The fact that you found one guy, who, six years ago, worked on using Forth as a hardware description language, does not mean it is a good idea. If that were true, why has nothing happened with it in the last six years?

People like to think that applying Forth to a problem, will make that problem simple to solve. Digital hardware logic design is not a simple task, not because of the tools used. The tools are complicated because the problem is complicated. The existing tools have simplified the work by hiding the complexity as much as possible. This works 99.9% of the time, allowing work to proceed with reasonable speed and accuracy. I can't see where Forth is going to help this at all.

--

Rick C.

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

[Jurgen Pitaske]

Well, there seems to be only "ONE PERSON" who does not like this.
As there are 2 or three people who see it as interesting,
your importance with your comments is going down to a third.
AND:
The number of your posts does NOT increase the importance or value.
And there might be a Forth Person anyway ...

[John Hart]

> > > > > > It's a tool of little value in the FPGA world. Homebrew amateurs may find it interesting, but the FPGA world will...

> Well, there seems to be only "ONE PERSON" who does not like this.

Jurgen,

As I read Rick's response I had to smile. Not knowing it, he summed up the reasons why authoritarian systems don't work. The reason Forth is useful is its extensibility; can be turned into any tool one wants, including a verilog code generator. Then, even if the result isn't perfect, one can edit the output to one's heart's content, which of course is what I do.

A more difficult aspect of logic design is verifying it works. To do so one needs a reference to compare with. Forth, being extensible, is the ideal tool, especially when designing a Forth processor.

To create the new processor's software model took about a week, and it was easy to modify as the design progressed. The SW model provides the data needed by the hardware simulator to verify the verilog code is working. Rapid specific feedback is the key to perfecting complex logic designs.

jrh

[Jurgen Pitaske]

What a great post John.
You just sum up what this tool Forth can be adapted to for your requirements.
And you help to spread the message what your implementation can be used for as well.

Will it replace VHDL? No
Will it replace Verilog - probably not.
But it is an additional tool as you use it and describe it.
I have just enough knowledge in this area to see it can be useful.
And when I saw it the first time I was impressed.
I hope you will post more about your approach
so others can understand it better and take advantage of it in their work.

Just an idea:
I could convince Steve Teal to write the Minimum RISC in VHDL.
And as a bonus he added an eForth.
https://github.com/Steve-Teal/eforth-misc16

How difficult would it be to replicate this design using your tools and Forth as VHDL?
And use the same FPGA you use now?

This would be a way to show others a full design,
using standard tools on one side,
and then compare it with your tools.
Your tools could then probably more easily show how to add additional IOs.

Thanks again - and can we have more please.

[Wayne morellini]

John, thank you. Looks interesting.

[Myron Plichota]

I respect Rick C's opinions on the art of FPGA design. IMHO his comments are incisive and reality-oriented. I'm pretty sure he has experience in the matter.

Anyone who aspires to create an original computer on an available FPGA eval board can do so using free tools with a choice of VHDL (boo!) and/or Verilog (yay!) HDLs. Icarus Verilog testbenches are *natural* outgrowths of Verilog modules.

Verilog already describes *the desired behaviour of any number of parallel processes, clocked or flow-through*. I don't see a need for an exotic "Forth" front end (to generate what?).

[John Hart]

\ Op Code File for MFX. Generated by MAKE-OPS v13

<clip>

> > > > > > > > > > > > > > The Logic Compiler is working and the modules for the processor are done and tested. After the mem interface module is complete we'll be ready to put the design into the fpga. We're using a X02-7000 but the design will work in any equivalent part.

<clip>

> > > > > > > > > > > Sorry, I don't follow. What are you describing by, "use VHDL on an FPGA to write to it directly in Forth"?
> > > > > > > > > > > If you are talking about a stack CPU, written in VHDL, running on an FPGA, that has been done
> > > > > > > > > > > many, many times, some published, many not published. It would seem to be a trivial exercise.

> > > > > > > > > > > Rick C.

Verilog, NOT VHDL. I found it to be too verbose.
And if you have a trivial solution to computer optimization, please post it!

(edited for clarity)

> > > > > > > > > > Designing logic with the Forth VHDL

> > > > > > > > > > 1. Write a software simulation of the design. (Forth with local varables and a MAP extension)
> > > > > > > > > > 2. Test the design. (test program, simple compiler and simulator written in Forth)
> > > > > > > > > > 3. Convert the simulation into a hardware definition. (ED-MGEN, ED-CTRL, ED-DFRW, ED-DCDM, ED-DSEL)
> > > > > > > > > > 4. Link instructions to modules. (EDIT-TRAN)
> > > > > > > > > > 5. Compile the hardware definition into logic equations. (GEN-MAP, CTRL-MAP & DFRW-MAP programs}
> > > > > > > > > > 6. Verify the logic equations work correctly. (EDIT-DISP, SIM-R32)
> > > > > > > > > > 7. Assign the I/O pins. (ED-PINS, able to parse the csv pin file and combine it with the schematic foot print)
> > > > > > > > > > 8. Fit the logic equations into the device. (Diamond from Lattice Semi does this, and there are universal ones)
> > > > > > > > > > 9. Convert the routed design into a fusemap. (Diamond)
> > > > > > > > > > 10. Compile the OS using the OP code definition file. (MAKE-OPS)
<clip>

> > > > > > > > > "Forth VHDL"??? You are talking about a VHDL synthesis tool written in Forth???
> > > > > > > > > No, that doesn't fit the description of what is going on.
> > > > > > > > > In fact, your description doesn't seem to relate to VHDL at all.
> > > > > > > > > I can't tell what you are talking about from this description,
> > > > > > > > > but it sounds like it is for CPLDs, rather than FPGAs.

> > > > > > > > > Rick C.
Our first CNC product had three 8032 processors. One for motion, One to process files, and one for I/O.
We replaced the motion and file processors with the RACE, (Reduced Architecture Computation Engine)
in our new controller realased in 2000. The RACE and 4 motor controllers fit into a 1048 CPLD from Lattice.
In 2016 we moved the design to an X02-7000 and eliminated the 8032.
The design wasn't optomized for a LUT based part and the OS was getting too large for the address space
so it was obvious we needed to update the design.

Using verilog tools and IP express, provided by Diamond, it took about two years to move our IP to the X02,
I've designed a wide variety of IP from servo system to networks and developed tools along to way to
assist in making such devices. For example the software from Lattice used for the RACE could only
achieve 80% ultization, I devised a tool that allowed us to achieve 100%,

Designing and debuging the software for rapid processor evolution was more difficult than anticipated, as
usual, but necessary for a reconfigurable product that could be used by small business having to compete
with large corporate monopolies that have gained control of the regulatory bodies and are using their
power to crush competion!

> > > > > > > Ah, so he's bastardizing the term VHDL. (there's a little bit of Hugh in everyone)

> > > > > > > > They used it on a CPLD first, and on a Lattice FPGA 7k now.
> > > > > > > > Hugh Aguilar was involved there.
> > > > > > > > And with all of the knowledge and experience here or elsewhere
> > > > > > > > it could probably be ported to
> > > > > > > > other FPGA families.

<clip>

> > > > > One of my early jobs involved designing a microprogrammed DMA controller using an off the shelf sequencer chip. The other, similar designs in the company all used the same assembler tool. I added a few macros and opcodes, in order to give my design additional self-test capabilities. One of the managers said that was a bad idea because no one else would know how to use this "different" tool. I realized that there are many times when standardization is preferred over technical advantages, because technical advantages are of no use if they make the design hard to work with or modify.
> > > > >
> > > > > In this case, there is no real utility to this "special" design process and it actually appears to be much more complex and difficult to use.
> > > > >

<clip>

> > > Trying to use Forth as the language to compose logic is solving a problem that doesn't exist. We have Verilog and VHDL as the mainstream languages for logic hardware design and they work well. There are efforts to use C for hardware logic design, which is seldom used. The main justification for using C is to have a common language for hardware and software, so the dividing line is easily moved, allowing one system design to be implemented in different ways with different performance levels. In reality, this is not at all simple to do. Hardware and software require interfaces. When you change the dividing line in the code for that interface and you have to redesign everything about that interface. So it is seldom used this way.
> > >
> > > I stand by my statement that using Forth for both software and hardware design is of little value. The fact that you found one guy, who, six years ago, worked on using Forth as a hardware description language, does not mean it is a good idea. If that were true, why has nothing happened with it in the last six years?
> > >
> > > People like to think that applying Forth to a problem, will make that problem simple to solve. Digital hardware logic design is not a simple task, not because of the tools used. The tools are complicated because the problem is complicated. The existing tools have simplified the work by hiding the complexity as much as possible. This works 99.9% of the time, allowing work to proceed with reasonable speed and accuracy. I can't see where Forth is going to help this at all.

> > > Rick C.
Each to their own. I've spent too much time on this, got to get back to work.

> Verilog already describes *the desired behaviour of any number of parallel processes, clocked or flow-through*.
>I don't see a need for an exotic "Forth" front end (to generate what?).

I don't know. You tell me.

[Lorem Ipsum]

On Sunday, October 16, 2022 at 4:22:36 PM UTC-4, johnro...@gmail.com wrote:
> \ Op Code File for MFX. Generated by MAKE-OPS v13
> <clip>
> > > > > > > > > > > > > > > The Logic Compiler is working and the modules for the processor are done and tested. After the mem interface module is complete we'll be ready to put the design into the fpga. We're using a X02-7000 but the design will work in any equivalent part.
> <clip>
> > > > > > > > > > > > Sorry, I don't follow. What are you describing by, "use VHDL on an FPGA to write to it directly in Forth"?
> > > > > > > > > > > > If you are talking about a stack CPU, written in VHDL, running on an FPGA, that has been done
> > > > > > > > > > > > many, many times, some published, many not published. It would seem to be a trivial exercise.
> > > > > > > > > > > > Rick C.
>
> Verilog, NOT VHDL. I found it to be too verbose.

If you think Verilog is verbose, don't even bother trying VHDL. Perhaps is it not you, but someone in the thread is using VHDL to stand for something other than its traditional meaning of VHSIC Hardware Description Language. This gets to be very confusing.

> And if you have a trivial solution to computer optimization, please post it!

Not sure what you are referring to.

Silicon is relatively inexpensive, these days. A project has to be very, very high volume to justify such an effort of optimization. I'm currently working on a redesign because of component optimization and I'm happy with 100% overkill on a new part, because the chip cost is only $5 each. I could use a $3 part, but it is 4 kLUT and the previous design was using 90% of a 3 kLUT part. Since it is a change of not just family, but brand, I don't look forward to spending excessive time shoehorning a design into a device. That makes alterations in the design prohibitively expensive as well.

Still, with a volume of perhaps 50,000 pieces, I might go with the smaller chip as long as I can share the footprint with the larger part.

> Designing and debuging the software for rapid processor evolution was more difficult than anticipated, as
> usual, but necessary for a reconfigurable product that could be used by small business having to compete
> with large corporate monopolies that have gained control of the regulatory bodies and are using their
> power to crush competion!
>
> > > > > > > > Ah, so he's bastardizing the term VHDL. (there's a little bit of Hugh in everyone)
> > > > > > > > > They used it on a CPLD first, and on a Lattice FPGA 7k now.
> > > > > > > > > Hugh Aguilar was involved there.
> > > > > > > > > And with all of the knowledge and experience here or elsewhere
> > > > > > > > > it could probably be ported to
> > > > > > > > > other FPGA families.
> <clip>
> > > > > > One of my early jobs involved designing a microprogrammed DMA controller using an off the shelf sequencer chip. The other, similar designs in the company all used the same assembler tool. I added a few macros and opcodes, in order to give my design additional self-test capabilities. One of the managers said that was a bad idea because no one else would know how to use this "different" tool. I realized that there are many times when standardization is preferred over technical advantages, because technical advantages are of no use if they make the design hard to work with or modify.
> > > > > >
> > > > > > In this case, there is no real utility to this "special" design process and it actually appears to be much more complex and difficult to use.
> > > > > >
> <clip>
> > > > Trying to use Forth as the language to compose logic is solving a problem that doesn't exist. We have Verilog and VHDL as the mainstream languages for logic hardware design and they work well. There are efforts to use C for hardware logic design, which is seldom used. The main justification for using C is to have a common language for hardware and software, so the dividing line is easily moved, allowing one system design to be implemented in different ways with different performance levels. In reality, this is not at all simple to do. Hardware and software require interfaces. When you change the dividing line in the code for that interface and you have to redesign everything about that interface. So it is seldom used this way.
> > > >
> > > > I stand by my statement that using Forth for both software and hardware design is of little value. The fact that you found one guy, who, six years ago, worked on using Forth as a hardware description language, does not mean it is a good idea. If that were true, why has nothing happened with it in the last six years?
> > > >
> > > > People like to think that applying Forth to a problem, will make that problem simple to solve. Digital hardware logic design is not a simple task, not because of the tools used. The tools are complicated because the problem is complicated. The existing tools have simplified the work by hiding the complexity as much as possible. This works 99.9% of the time, allowing work to proceed with reasonable speed and accuracy. I can't see where Forth is going to help this at all.
> > > > Rick C.
> Each to their own. I've spent too much time on this, got to get back to work.
> > Verilog already describes *the desired behaviour of any number of parallel processes, clocked or flow-through*.
> >I don't see a need for an exotic "Forth" front end (to generate what?).
> I don't know. You tell me.

I haven't seen anything that would seem to be a Forth description of hardware in this thread, so I can't judge if it is better than one of the existing HDLs or not. But it would need to be pretty good to make it worth learning a new tool and then to try to get it to produce VHDL that commonly available tools can use optimally.

--

Rick C.

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

[Jurgen Pitaske]

Thank you very much again for investing the time of your post.
It was a bit difficult to read on my screen, so I copied parts out and edited it into a PDF for easier reading.
So I can as well share it
The file Forth as VHDL v1 there
https://www.dropbox.com/sh/ah8umk0hgq1818s/AAC8nNEueZZcIYJ8uGP4F4wPa?dl=0

I find Rick's arrogance rather funny as he does not show competence anymore.
He admits he has not seen a design to look at
but critizises and kills it anyway.

His way of professional approach to design for his customers?
What a piece of BS.
If a new design approach is described, it cannot be finished, otherwise it would not ne new by definition.
Please tell us more, so people here ( except Rick obviously ) can better understand, appreciate or even replicate.

As you state you use parts of Diamond anyway - so you know this Lattice tool for your FPGAs,
but your approach must have the advantages you describe.

To avoid misunderstandings, you should probably say " Forth-to-Gates including some Diamond" - ForthHDL.
And HDL rather than VHDL.
I cannot understand Rick's obsession to get the VHSIC Hardware Description Language in again and again
https://en.wikipedia.org/wiki/VHDL
I wonder how many here would know what VHSIC means ...

Please show us more as you have time.

It reminds me somehow of how Forth started - as a tool for Chuck,
Here it is a tool for you and for Testra.
Chuck did not care about the opinion of others, still now does what he enjoys - and many do not understand.

[Wayne morellini]

On Monday, October 17, 2022 at 6:22:36 AM UTC+10, johnro...@gmail.com wrote:
> \ Op Code File for MFX. Generated by MAKE-OPS v13

..

> Each to their own. I've spent too much time on this, got to get back to work.
> > Verilog already describes *the desired behaviour of any number of parallel processes, clocked or flow-through*.
> >I don't see a need for an exotic "Forth" front end (to generate what?).
> I don't know. You tell me.

John. Wayne here. I can't really read what you have done, as I've had a covid induced toxoplasma neurological spread from low immune system. But I encourage you here, as it is always good to have people that can design something new and practical. These things may at first often not look so practical in the light of present standards, but time will tell. As I posted many years ago, I had a desire to make the first game system with a hardware description language extension, as a way to put it in performance competition at reduced price with major players. Of course, I heard the same objections. But, when you do a deal with the supplier to have a setup where you have software that allows description generation for the single type of fpga in the system, such objections do not apply. But, as a general fpga description language, this message s something fpga manufacturers can get behind. There was a big push before for such tools to take an C language program and convert to DSP, fpga and GPU etc, to distribute the functionality accross the computer environment. So, you are on the money there. A combination of a minimal CPU core and fpga is very dynamic, considering how little space such cpu can take up, and speed and low energy they can take up. So thinkers and solution finders welcome, for my part. It's much more exciting to hear how somebody conquered a new problem/solution then to listen to objections to trying to solve things in a new way. In the end such things can have unforseen/misunderstood benefits. Your practical success of the years, shows that the bulk of the work, from your intuition, was right from the beginning. Not trying to blow up your head or anything, but it is the principle of the inventive process that others do not get. Tesla, the great Japanese inventor )whoes name escapes me at the moment) etc got this, producing volumes of foundation in short periods I can't say the same for other popularised Business men, who were called "genius" for attaching their names to others work, who were really like the level skilled of lab assistants, able to practically build on others foundational work, but not able to really do very much foundational work themselves.

One day, we might get a developers think tank like forum up and running, and it would be good to have people such as yourself along, and some practical builders (please be warned though, we are thinking of inviting a certain member due to his passionate foresight). :)

We can all do more foundational work together than divided.

Thanks.

[Wayne morellini]

On Monday, October 17, 2022 at 4:29:33 PM UTC+10, jpit...@gmail.com wrote:
..
> Please show us more as you have time.
>
> It reminds me somehow of how Forth started - as a tool for Chuck,
> Here it is a tool for you and for Testra.
> Chuck did not care about the opinion of others, still now does what he enjoys - and many do not understand.

But to understand others aswell, that's the trick.

It's all a bit funny. Instead of me doing my own product I was told to act in ways against it, and get the micromite, or some other such named microcomputer. If there is an open source, miniature fpga multimedia/retro computer, maybe you could add b16 orr ep32 too it, but it's not its own product then, and what you add may get caught up in the open source pool. Still, that would be an interesting thing. But, there is a lot of contrary stuff which happens. I really appreciate Jeff's efforts. He had something we could still be using, which could still be shifting in products today, but it never came out (things went awry). He's the one that nailed the x86 instructions for colorforth and machine forth. We owe a lot to him. The lowest end cell phone, and watch, bar might not be too high compared to that starting design, but with many higher level things, the bar is much higher now, and we need a revised new design to be at that level. If anybody can do fpga at near custom silicone, then it would be easier to get there. At the moment, for the retro designs I'm looking at custom designs within the range of FPGA's, using a basic respin of hardware technology back then, which is great for 1970's and 1980's, early 1990's not for today. Around here, doesn't seem as design adventurous as it once was.

[none albert]

In article <c1720c64-6805-4bf0...@googlegroups.com>,

Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
>On Sunday, October 16, 2022 at 4:22:36 PM UTC-4, johnro...@gmail.com wrote:

<SNIP>

>> Using verilog tools and IP express, provided by Diamond, it took about two years to move our IP to the X02,
>> I've designed a wide variety of IP from servo system to networks and developed tools along to way to
>> assist in making such devices. For example the software from Lattice used for the RACE could only
>> achieve 80% ultization, I devised a tool that allowed us to achieve 100%,
>
>Silicon is relatively inexpensive, these days. A project has to be very, very high volume to justify such an effort of optimization. I'm currently working
>on a redesign because of component optimization and I'm happy with 100% overkill on a new part, because the chip cost is only $5 each. I could use a $3
>part, but it is 4 kLUT and the previous design was using 90% of a 3 kLUT part. Since it is a change of not just family, but brand, I don't look forward to
>spending excessive time shoehorning a design into a device. That makes alterations in the design prohibitively expensive as well.
>
>Still, with a volume of perhaps 50,000 pieces, I might go with the smaller chip as long as I can share the footprint with the larger part.

You overlook an important detail. The company doesn't save on silicon.
They create value based on proprietary silicon that can not easily be
reverse engineered by others.
>--
>
>Rick C.

[Lorem Ipsum]

On Monday, October 17, 2022 at 7:26:26 AM UTC-4, none albert wrote:
> In article <c1720c64-6805-4bf0...@googlegroups.com>,
> Lorem Ipsum <gnuarm.del...@gmail.com> wrote:
> >On Sunday, October 16, 2022 at 4:22:36 PM UTC-4, johnro...@gmail.com wrote:
> <SNIP>
> >> Using verilog tools and IP express, provided by Diamond, it took about two years to move our IP to the X02,
> >> I've designed a wide variety of IP from servo system to networks and developed tools along to way to
> >> assist in making such devices. For example the software from Lattice used for the RACE could only
> >> achieve 80% ultization, I devised a tool that allowed us to achieve 100%,
> >
> >Silicon is relatively inexpensive, these days. A project has to be very, very high volume to justify such an effort of optimization. I'm currently working
> >on a redesign because of component optimization and I'm happy with 100% overkill on a new part, because the chip cost is only $5 each. I could use a $3
> >part, but it is 4 kLUT and the previous design was using 90% of a 3 kLUT part. Since it is a change of not just family, but brand, I don't look forward to
> >spending excessive time shoehorning a design into a device. That makes alterations in the design prohibitively expensive as well.
> >
> >Still, with a volume of perhaps 50,000 pieces, I might go with the smaller chip as long as I can share the footprint with the larger part.
> You overlook an important detail. The company doesn't save on silicon.
> They create value based on proprietary silicon that can not easily be
> reverse engineered by others.

You might want to define "easily". The bitstream for a number of Lattice devices has been reverse engineered to the point that there are open source tools that do not rely on any part of the Lattice tools. So how hard can it be to reverse engineer the design?

"For example the software from Lattice used for the RACE could only achieve 80% ultization, I devised a tool that allowed us to achieve 100%,"

I assume this meant he was trying to stay in a given size part. Regardless, I recall from the early days when users would complain to Xilinx that they could only use 90% of the logic in the device, that Xilinx would reply, "We sell you the routing and give you the logic for free", meaning, it would be cost prohibitive to supply adequate routing to achieve 100% use of the logic for every design. Every design has different demands on the routing, so some users' designs are limited by the logic in an FPGA, others' are limited by the routing. That makes perfect sense to me. Achieving 100% utilization of a part is not a useful goal in design work. Getting your design completed in the schedule and budget is normally the important goal.

I recall Hugh talking about how important it was to implement the design in a CPLD rather than a more expensive FPGA because of the cost. I assume Hugh knew something about this, but perhaps not. I believe there are some differences in the accounts of Hugh's involvement.

--

Rick C.

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

[Jurgen Pitaske]

WHAT A SURPRISE.
YOU CANNOT REMEMBER WHAT YOU READ 3 YEARS AGO.
YOU CANNOT REMEMBER WHAT YOU THEN POSTED 3 YEAR AGO.
YOU JUST MAKE IT UP AS YOU THINK IT SUITS.
BUT IT IS ALL DOCUMENTED IN THE THREAD FROM THEN

https://groups.google.com/g/comp.lang.forth/c/wydQr643gX0?pli=1

[dxforth]

On 18/10/2022 12:47 am, Lorem Ipsum wrote:
>
> I recall Hugh talking about how important it was to implement the design in a CPLD rather than a more expensive FPGA because of the cost. I assume Hugh knew something about this, but perhaps not. I believe there are some differences in the accounts of Hugh's involvement.

I don't recall Hugh ever claiming involvement in the design of the chip
(quite the opposite) but as he was employed to write software in support
of it, he would have gathered various info from the team that did. He's
makes it clear his knowledge of the chip was second-hand:

https://groups.google.com/g/comp.lang.forth/c/moqYqLF64v8/m/BKuFAWlUfEYJ

[Lorem Ipsum]

No, I'm not saying Hugh was involved in designing the CPLD. He simply talked about it being designed. That's why I said I assume he had knowledge of it, but maybe not. It was hard to have a conversation with Hugh. He would go off his nut at very little or even NO provocation at all. Reminds me of some other people here.

I remember trying to talk Hugh off a ledge a number of times, getting him to see that people here were not out to get him, it's just the way people are on the Internet sometimes. Again, reminds me of other people here. One in particular is obsessed with righting wrongs or whatever, by stirring the pot himself in the name of "justice" and clearing his good name. I try not to respond to those people. It seldom is productive in any manner.

But this post is not really useful in this thread. I just wanted to clarify that I didn't think Hugh was directly involved in designing any of the hardware. Heck, from the conversations with him, it was clear that he had no knowledge of designing any sort of PLD. He did want to do something, but had no idea where to begin really, and would not accept any advice either.

--

Rick C.

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

[Wayne morellini]

Oh come on. Talk him off a ledge, in which direction?! Even here we see somebody's passive aggressive half baked attitude is the problem! Give up trying to win and going off on these tangents. John's got a point and products, good on him. It does not matter what you think, he has functional ideas implenented, you don't have to use or under mine them. A few people got a bit of a loose screw here, and it's not I. I'm impressed you have a 50k run instead of 5k I was suspecting, but just realised (apart from it not being the different dynanics of a much more intricate 1-5 million plus consumer electronic run being debated previously), you are not as good as when I first met you here many years ago, and most of us aren't. I myself am looking forwards to attempting to do things a fraction of the complexity I once was, and your ability is not what it used to be either. I genuinely feel sorry for High. I know what it's is like to have a few individuals trying to subvertly trying to antagonise, while making out they are not. Some people can't handle that pressure. I believe Hugh can do great things, I'm not negative on that. But every garden has to be grown, not trampled because it's not somebody else's type of garden!

Neurones are rewiring! :)

[dxforth]

On 20/10/2022 12:36 am, Wayne morellini wrote:
>
> But every garden has to be grown, not trampled because it's not somebody else's type of garden!

The 'Steve' from this thread might be interested in being your gardener:

https://groups.google.com/g/comp.lang.forth/c/fDUuqeiXw0A/m/JJH5DJhxcoYJ

[Wayne morellini]

Now, now, no passive aggressive games. You know I'm talking about Hugh needing a gardner. Face it, if we help each other, a lot more would get done. Victimising people of practical talent, is not going help. Even I've thought of going into candle making. It would be a mediocre waste of my talent, if I got well enough to keep up, and not much of a living. I have trouble even finding the email icon and operating email in the last year, simple stuff, and that's as a computer scientist that should be designing such things. So, I've got a long way to go to get back into a descent normal range, and I may have to spend my life at 10%, but I'm an insanely good thinker and real writer, so that's the last things to really go. I get below 10% and it gets bad and a life sapping struggle, 1% and it's real bad. 0.1% and nothing is happening at all. Tick born diseases are the pits, and it's a struggle just to stay above 10 or 50%, not to mention hyper infections of toxo from tick born diseases lowering the immune system (and covid). I thought I might not last till the end of the year a few months ago, before I figured out what was happening and subdued the toxo somewhat. It's a word of warning, this thing is coming fur most people. Sooner or later, the body is going lower the immune system and its going take off like it never does in healthy people, and wreck organs and brain. To do something about it, might be a long and healthy life. The people complained about around here (and it's expected many autism spectrum people) are likely to have some bacterial, fungus and/or parasitical overgrowth. But Asperger's people tend to hold onto some rationality more, so it's not as obvious that's what's happening. Some people get it before very old some get it due to poor constitution younger. It's an active feild of research and one of the most under treated areas of the past (as healthy test subjects and professionals don't represent those people). A the super active stuff, is without those things. 'Do you want the last 90% of your energy? Then Uncle ... Wants You' (for our eastern European members, that's a reference to the old American "Uncle Sam" army recruiting posters). Our countries are living in a hodge podge of humiliating mess. But, without disease, people tend towards becoming Frankenstein's Monster, shallow, emotionally locked on, greedy, and unbalanced too. We are archeiving 10-20 percent in some western societies. Imagine achieving 100 years of technology progress on 10 years. Many of pot current population resource consumption problems could be fixed, in 10 years. That means that in the last 100 years we could have made 1000 years progress,vans skipped a lot of ecological problems! Amazing!

[dxforth]

On 20/10/2022 11:52 pm, Wayne morellini wrote:
> On Thursday, October 20, 2022 at 10:41:57 AM UTC+10, dxforth wrote:
>> On 20/10/2022 12:36 am, Wayne morellini wrote:
>>>
>>> But every garden has to be grown, not trampled because it's not somebody else's type of garden!
>> The 'Steve' from this thread might be interested in being your gardener:
>>
>> https://groups.google.com/g/comp.lang.forth/c/fDUuqeiXw0A/m/JJH5DJhxcoYJ
>
> Now, now, no passive aggressive games. You know I'm talking about Hugh needing a gardner.

All I saw was metaphors about growing gardens and not allowing others to
trample it.

> Face it, if we help each other, a lot more would get done.

Perhaps c.l.f. doesn't need your help. It gets plenty of free offers as it
is - largely rejected, same as yours.

Why don't you chase up 'Steve' as he seems to hold similar interests to your
own. He appeared to concede c.l.f wasn't the best place for his growing his
MISC garden.

[S]

On Friday, October 21, 2022 at 12:39:01 PM UTC+10, dxforth wrote:
> On 20/10/2022 11:52 pm, Wayne morellini wrote:
> > On Thursday, October 20, 2022 at 10:41:57 AM UTC+10, dxforth wrote:
> >> On 20/10/2022 12:36 am, Wayne morellini wrote:
> >>>
> >>> But every garden has to be grown, not trampled because it's not somebody else's type of garden!
> >> The 'Steve' from this thread might be interested in being your gardener:
> >>
> >> https://groups.google.com/g/comp.lang.forth/c/fDUuqeiXw0A/m/JJH5DJhxcoYJ
> >
> > Now, now, no passive aggressive games. You know I'm talking about Hugh needing a gardner.

> All I saw was metaphors about growing gardens and not allowing others to
> trample it.

Now. It was pretty obvious we were just talking about somebody in particular, who had been badly treated here.

> > Face it, if we help each other, a lot more would get done.
> Perhaps c.l.f. doesn't need your help. It gets plenty of free offers as it
> is - largely rejected, same as yours.

We were talking about helping one another in the context of helping somebody in particular. Look up Look up contrasting and context.

We simply don't need your help!

[dxforth]

On 21/10/2022 2:10 pm, S wrote:
> On Friday, October 21, 2022 at 12:39:01 PM UTC+10, dxforth wrote:
>> On 20/10/2022 11:52 pm, Wayne morellini wrote:
>>> On Thursday, October 20, 2022 at 10:41:57 AM UTC+10, dxforth wrote:
>>>> On 20/10/2022 12:36 am, Wayne morellini wrote:
>>>>>
>>>>> But every garden has to be grown, not trampled because it's not somebody else's type of garden!
>>>> The 'Steve' from this thread might be interested in being your gardener:
>>>>
>>>> https://groups.google.com/g/comp.lang.forth/c/fDUuqeiXw0A/m/JJH5DJhxcoYJ
>>>
>>> Now, now, no passive aggressive games. You know I'm talking about Hugh needing a gardner.
>
>> All I saw was metaphors about growing gardens and not allowing others to
>> trample it.
>
> Now. It was pretty obvious we were just talking about somebody in particular, who had been badly treated here.

Identifying oneself with Hugh doesn't make for a great C.V. With the exception of
one person who admitted an axe to grind, I don't believe Hugh was treatly badly here
at all. Often his own worst enemy, he burned every bridge he crossed.

>
>>> Face it, if we help each other, a lot more would get done.
>> Perhaps c.l.f. doesn't need your help. It gets plenty of free offers as it
>> is - largely rejected, same as yours.
>
> We were talking about helping one another in the context of helping somebody in particular. Look up Look up contrasting and context.
>
> We simply don't need your help!

Look forward to the day you can say that to everyone.

[S]

On Friday, October 21, 2022 at 3:19:27 PM UTC+10, dxforth wrote:
> On 21/10/2022 2:10 pm, S wrote:
> > On Friday, October 21, 2022 at 12:39:01 PM UTC+10, dxforth wrote:
> >> On 20/10/2022 11:52 pm, Wayne morellini wrote:
> >>> On Thursday, October 20, 2022 at 10:41:57 AM UTC+10, dxforth wrote:
> >>>> On 20/10/2022 12:36 am, Wayne morellini wrote:


> >>> Now, now, no passive aggressive games. You know I'm talking about Hugh needing a gardner.
> >
> >> All I saw was metaphors about growing gardens and not allowing others to
> >> trample it.
> >
> > Now. It was pretty obvious we were just talking about somebody in particular, who had been badly treated here.
> Identifying oneself with Hugh doesn't make for a great C.V. With the exception of
> one person who admitted an axe to grind, I don't believe Hugh was treatly badly here
> at all. Often his own worst enemy, he burned every bridge he crossed.

Good on him. The quality of people coming against him was incredible, and dishonestly making believe about him and their intentions.. For instance, mixing everything up. I don't see myself identified with Hugh, he's different, I just value people, the better the human they are. I know plenty about themselves.

> >>> Face it, if we help each other, a lot more would get done.
> >> Perhaps c.l.f. doesn't need your help. It gets plenty of free offers as it
> >> is - largely rejected, same as yours.
> >
> > We were talking about helping one another in the context of helping somebody in particular. Look up Look up contrasting and context.
> >
> > We simply don't need your help!
> Look forward to the day you can say that to everyone.

Mixing things up. We were talking about people helping people, not everybody not helping anybody. Let's get on, and stop derailing the thread. I've pretty much covered it was bad, John, Hugh et al, being mistreated.

[dxforth]

On 21/10/2022 4:44 pm, S wrote:
> On Friday, October 21, 2022 at 3:19:27 PM UTC+10, dxforth wrote:
>> On 21/10/2022 2:10 pm, S wrote:
>>> On Friday, October 21, 2022 at 12:39:01 PM UTC+10, dxforth wrote:
>>>> On 20/10/2022 11:52 pm, Wayne morellini wrote:
>>>>> On Thursday, October 20, 2022 at 10:41:57 AM UTC+10, dxforth wrote:
>>>>>> On 20/10/2022 12:36 am, Wayne morellini wrote:
>
>
>>>>> Now, now, no passive aggressive games. You know I'm talking about Hugh needing a gardner.
>>>
>>>> All I saw was metaphors about growing gardens and not allowing others to
>>>> trample it.
>>>
>>> Now. It was pretty obvious we were just talking about somebody in particular, who had been badly treated here.
>> Identifying oneself with Hugh doesn't make for a great C.V. With the exception of
>> one person who admitted an axe to grind, I don't believe Hugh was treatly badly here
>> at all. Often his own worst enemy, he burned every bridge he crossed.
>
> Good on him. The quality of people coming against him was incredible, and dishonestly making believe about him and their intentions.. For instance, mixing everything up. I don't see myself identified with Hugh, he's different, I just value people, the better the human they are. I know plenty about themselves.

Yes, the value you place on people is boundless...

Sep 6, 2022, 10:07:48 PM

"But I, like many intelligent people, just leave them alone to their own delusions.
You can only help certain people."

Worthy of a Nobel Prize for humanity.

[S 1]

What are you quoting? But it is certain, you can only do so much, and some are too pathologically disrupted to be able to help further. Meaning they interfere, and will not listen. Moles and trolls.

I'm sorry if you have a need to follow people around, but I'm not interested. It may be good, if you stop derailing thread DX. The relevant side topics of how people have been addressed here have been addressed.

[dxforth]

I'm not responsible for your priorities - or lack thereof. There'd be nothing to discuss
if it wasn't for your "side topics". The image of yourself as a great innovator and how
you have been hard done by pervades all your posts. So yeah - if you can leave all that
behind it would be great. But I seriously doubt you can. It's why you've been compared
with other infamous characters on c.l.f.

[S 1]

What a nutty sentence. You got nothing to say a relevance,again, by the looks of it.

No, it's just you being nutty again! As can be seen from your above conversation. If you are jealous of people getting it right, maybe you should try being right instead? If you lack innovation, get some or shut up, stop going on like you are a jealous school girl! You are just being rude and trolling again, who doesn't want to listen. Expressing what (shade) you like to think, with no credible reason to do so. Not a better human to be helped. Wake up and go away!. There is 0 need for you here doing this ego driven garbage.

Thank you.

[dxforth]

On 23/10/2022 2:28 am, S 1 wrote:
> ...> If you are jealous of people getting it right, maybe you should try being right instead? If you lack innovation, get some or shut up, stop going on like you are a jealous school girl!

So what you have actually accomplished and of which others could rightly be jealous?
I haven't read all of your posts and it's possible I missed it among the accounts of
opportunities never realized and people that failed you. So, yes, please list your
accomplishments. It just may get you the help for which you constantly make appeal.

[S]

Unbelievable, you being a pest to people, you haven't read up, don't know what you are talking about, and have achieved nothing but pestering, and shifting around.

[dxforth]

I'm not the one selling myself - you are. The question was simple enough. What can
you show people you have practically achieved that would make it worth their while
partnering with you. Your ability to exaggerate your importance isn't in doubt e.g.
offering to bring a thousand new members to c.l.f. What's lacking is evidence you
can bring anything to a conclusion. Even if it's just a series of posts.

[John Hart]

On Thursday, November 25, 2021 at 2:39:20 AM UTC-7, Jurgen Pitaske wrote:
<clip>
> Thank you very much John - let's see what happens next.
> Just for the fun of it I formatted it slightly in a way that makes the blocks a bit clearer to me
> https://www.dropbox.com/sh/ah8umk0hgq1818s/AAC8nNEueZZcIYJ8uGP4F4wPa?dl=0

Finally getting close to finishing the development system and the processor.

The original design was for a FPLD not a FPGA. After we moved the design to a FPGA it became obvious
a major re-design was needed. PLD's are optimized for parallel operations and we were able to convert
forth code directly to logic for the design, but FPGA's require something more complex, so I decided to
build a map generator before beginning the project.

[Jurgen Pitaske]

Looking forward to more ...

And I just checked the dropbox link - still works.
I hope the formatting was helpful.

[Lorem Ipsum]

What additional complexity do FPGAs require over CPLD? I literally have no idea what that means. You can use the same HDL code that was written for a CPLD (assuming there's a compiler for it) and compile that for an FPGA.

I can't think of anything that is harder to do in an FPGA than in a CPLD, unless CPLDs have something akin to "long lines" which FPGAs used to use, until they grew out of them with logic being faster.

There is nothing about FPGAs to preclude or make harder parallel operations. FPGAs are the embodiment of parallel operations. Every component on an FPGA operates in parallel with all the others, unless you tie them to sequential operations in your code.

--

Rick C.

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

[Hugh Aguilar]

On Tuesday, October 11, 2022 at 11:23:30 PM UTC-7, Jurgen Pitaske wrote:
> Just an idea:
> I could convince Steve Teal to write the Minimum RISC in VHDL.
> And as a bonus he added an eForth.
> https://github.com/Steve-Teal/eforth-misc16
>
> How difficult would it be to replicate this design using your tools and Forth as VHDL?
> And use the same FPGA you use now?
>
> This would be a way to show others a full design,
> using standard tools on one side,
> and then compare it with your tools.
> Your tools could then probably more easily show how to add additional IOs.
>
> Thanks again - and can we have more please

Juergen Pintaske assumes that the Testra development tools (including MFX)
are an internet freebie that anybody can download, similar to eForth.
This isn't true though. I wrote MFX in 32-bit UR/Forth under a DOS-extender
in 1994. I was told that Testra had the sign an NDA for Ray Duncan in order to
obtain the UR/Forth source-code. Since that time, Testra has upgraded UR/Forth
to run under Windows, so they could continue to use UR/Forth all the way to 2023.
The NDA is still in effect. Testra can't distribute MFX or any of the other development
tools to anybody who doesn't also sign the NDA for Ray Duncan.

In 1994 I was well aware of the problem with UR/Forth being a dead-end because LMI
(Ray Duncan's company: Laboratory Microsystems Inc.) had been killed by ANS-Forth.
This is why I only wrote a minimal amount of x86 assembly-language that would
required carnal-knowledge of UR/Forth, and I put all of this UR/Forth-specific code in
one file. My expectation was that MFX would later be ported to another Forth compiler
that was still being supported, and only this one small file would need to be rewritten.
Everything else in MFX was Forth-83 or, if it was UR/Forth specific, it didn't use any
carnal-knowledge or x86 assembly so it would be easy enough to port to another Forth.
Testra continues to use UR/Forth though! This is because neither John Hart or Steve Brault
know enough about MFX to port it to another Forth system, and they have never been
able to find any maintenance programmer who could learn MFX either.

On Friday, July 23, 2021 at 1:43:39 AM UTC-7, John Hart wrote:
> Hugh appears to be stuck in a time loop, like Phill Connors in Ground Hogs Day.

John Hart continues to use UR/Forth three decades after LMI went out of business.
John Hart does this so he can keep MFX running decade after decade.
John Hart is stuck in a time loop, like Phil Conners in the movie: "Ground Hog Day."
For John Hart, it will always be 1994 and he will always be running MFX under UR/Forth.
Just like in the movie, every day that John Hart wakes up it is 1994 again and he is running
my MFX under UR/Forth --- this time loop is John Hart's personal hell that never ends.

My recollection of working at Testra is that Tom Hart would show up for an hour or two
every two or three weeks. Tom Hart most likely doesn't know that I wrote MFX or even
know what MFX is. John Hart does know that I wrote MFX. It has been several years now
and John Hart has never admitted on comp.lang.forth that I wrote MFX. John Hart is a liar!
The truth is that I wrote MFX, and his refusal to admit the truth makes him a liar.
I think that John Hart is ashamed of the fact that he didn't know how to write an
assembler/simulator for his MiniForth processor and had to hire outside help to do this.
He has spent the last three decades telling the lie that he and Steve Brault wrote MFX
and now he can't tell the truth because doing so would require him to admit that he lied.

On Friday, July 23, 2021 at 1:43:39 AM UTC-7, John Hart wrote:
> His brother worked for us after he left on the HPGL converter, not Hugh.
> When he complained about it,
> I explained that Tom was confused about that, and thought that would be the end of it.

John Hart is a liar! He has now upgraded to attacking my family members with his filthy lies.
Also, when I visited Testra, John Hart did not explain to me about Tom being confused.
John Hart invented this lie about my brother years later to cover up the lie about me failing
to learn HPGL (I never even heard of HPGL until I got hit with this lie on comp.lang.forth).
Attacking family members is loathsome behavior, even by the low standards of comp.lang.forth..

On Tuesday, April 25, 2023 at 10:13:11 AM UTC-7, John Hart wrote:
> Finally getting close to finishing the development system and the processor.

John Hart is "finally getting close to finishing" in the year 2023. LOL
Using UR/Forth in the year 2023 is like competing in the Indianapolis 500 with a Model-T Ford.
Long after the race is over and all of the spectators have gone home, John Hart is
finally getting close to finishing the race. His Model-T Ford is zooming toward the finish line
at 20 mph! He is still using MFX although he doesn't understand how MFX works, just like a
race-car driver who doesn't understand how the internal-combustion engine works.

[John Hart]

On Tuesday, April 25, 2023 at 6:23:15 PM UTC-7, Lorem Ipsum wrote:
> On Tuesday, April 25, 2023 at 1:13:11 PM UTC-4, John Hart wrote:
> > On Thursday, November 25, 2021 at 2:39:20 AM UTC-7, Jurgen Pitaske wrote:
> > <clip>

<clip>

> > The original design was for a FPLD not a FPGA. After we moved the design to a FPGA it became obvious
> > a major re-design was needed. PLD's are optimized for parallel operations and we were able to convert
> > forth code directly to logic for the design, but FPGA's require something more complex, so I decided to
> > build a map generator before beginning the project.
> What additional complexity do FPGAs require over CPLD? I literally have no idea what that means. You can use the same HDL code that was written for a CPLD (assuming there's a compiler for it) and compile that for an FPGA.
>
> I can't think of anything that is harder to do in an FPGA than in a CPLD, unless CPLDs have something akin to "long lines" which FPGAs used to use, until they grew out of them with logic being faster.
>
> There is nothing about FPGAs to preclude or make harder parallel operations. FPGAs are the embodiment of parallel operations. Every component on an FPGA operates in parallel with all the others, unless you tie them to sequential operations in your code.

> Rick C.

The basic logic unit of a FPGA is a LUT, typically 4 or 5 inputs. The basic logic unit of a CPGA has 16 to 20 inputs.
A 5 input LUT can decode all possible inputs, the basic logic unit of a FPGA, only 4 to 20. A large adder in a CPLD
is next to impossible, in a FPGA a simple task and with carry logic, trivial. The ALU in our Forth CPLD processor was
4 bits. Todays FPGAs outperform CPLDs to the point they're obsolete.

[John Hart]

I might provide the current instruction set in a more useful form after our product is finished, if there's any
interest. It's a universal 16 axis motion control system with two syncronized PWM outputs for laser, plasma,
3D printer, etc control.

After the processor is finished I was thinking about releasing the development tool in an open source format.
To perfect it will require a joint effort. Reconfigurable Processors have many advantages over fixed ones and
a variable instruction set could provide a level of security that would be very difficult to crack.

[dxforth]

On 27/04/2023 4:07 am, Hugh Aguilar wrote:
>
> I wrote MFX in 32-bit UR/Forth under a DOS-extender
> in 1994. I was told that Testra had the sign an NDA for Ray Duncan in order to
> obtain the UR/Forth source-code. Since that time, Testra has upgraded UR/Forth
> to run under Windows, so they could continue to use UR/Forth all the way to 2023.
> The NDA is still in effect. Testra can't distribute MFX or any of the other development
> tools to anybody who doesn't also sign the NDA for Ray Duncan.

It was true when they signed it. IP needs to be enforced and it's not clear who -
if anyone - owns LMI's IP today. Certainly no one other than yourself has come
forward to insist LMI's IP be respected. Much like the priest who speaks for a
God that can be seen or felt, threatening destruction if they don't get it.

[Lorem Ipsum]

I don't disagree with what you write. I just don't understand how it relates to the statement, "FPGA's require something more complex".

My understanding is that a CPLD is hard to program complex functions in, while is it much less difficult to do so in an FPGA. Are you trying to say that it's only worthwhile to use FPGAs for more complex logic?

--

Rick C.

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

[Jurgen Pitaske]

It is not clear to anybody here why you are just adding useless noise here .

If you do not know what CPLD / FPGA means
- there is a so called internet where you can find the information and understanding you are missing.
Or build your own.
In hardware
as CPLD for practice
Or in FPGA - here go to NandLand invest the money and start programming
or dig out the TTLs you should still have and build your own
http://blog.notdot.net/2012/10/Build-your-own-FPGA

[Jurgen Pitaske]

An option might be to release the older CPLD version first,
which is probably not used anymore ( if the chip is still available )
as it is probably easier to understand.

I look really forward to more from you.
And this might as well enlighten the post on your website about Forth to FPGA

[Lorem Ipsum]

Thank you for your kind words of support and encouragement. Everyone says how marvelous it is that we have you to guide us and teach us.

I feel wiser, just having read your remarks.

--

Rick C.

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

[John Hart]

> Rick C.
Not at all. Today FPGAs are better than PLDs for most everything, even small jobs. Our PLD based processer was written in Forth and mapped directly into logic equations that fit the format of the PLD. When we moved the design to the FPGA the
logic compiler had to factor the equations into pieces that would fit in LUTs. Optimization for a PLD is the opposite of
optimizastion for a FPGA. Minimizing terms, which was very important for the PLD, was completely useless. Compile time was long and it required hand optimization to reach the performance goal.

Our new processor is more complex and experience told me better tools would be necessary to complete the project, so
I spent more time on tools than the design at first. There are many parts to the FPGA4th system that produces
VERILOG code for data and control of modules , I/O pin assignments, and definition of the instruction set for the assembler.
The part that converts the instruction set into equations was the hardest and might be simplified by re-doing it without recursion.

[Jurgen Pitaske]

I do appreciate your sarcasm.

But looking at Rick Collins on LinkedIN again now
https://www.linkedin.com/in/ariusinc/
it states there:

About
Digital and analog board level design and production with DSP and FPGA in Verlog/VHDL with embedded software.

A current design that Arius is producing for a major communications company is an IRIG-B/Audio interface for their IP networking equipment.
This product has passed acceptance testing and Arius, Inc is now producing these units for sale in our customer's equipment.

We utilize an optimal combination of tried and tested approaches with state of the art technology to deliver low cost solutions meeting our customer's cost, schedule and design goals.

Specialties: FPGA design (Xilinx, Altera, Lattice), VHDL, Verilog
High speed digital circuit board design
Analog circuit design
ARM7 and Cortex M3 software development
TMS320C6xxx and TMS320C5xxx processor design
Low Power
Miniaturization
Prototyping
Volume Production
Automated Testing

So, I hope you were able to understand that my post contsained a bit of sarcasm as well ...

[Hugh Aguilar]

On Wednesday, April 26, 2023 at 5:59:22 PM UTC-7, John Hart wrote:
> On Tuesday, April 25, 2023 at 6:23:15 PM UTC-7, Lorem Ipsum wrote:
> > I can't think of anything that is harder to do in an FPGA than in a CPLD,
> > unless CPLDs have something akin to "long lines" which FPGAs used to use,
> > until they grew out of them with logic being faster.
> >
> > There is nothing about FPGAs to preclude or make harder parallel operations.
> > FPGAs are the embodiment of parallel operations. Every component on an
> > FPGA operates in parallel with all the others, unless you tie them to sequential
> > operations in your code.
> > Rick C.
>
> The basic logic unit of a FPGA is a LUT, typically 4 or 5 inputs.
> The basic logic unit of a CPGA has 16 to 20 inputs.
> A 5 input LUT can decode all possible inputs, the basic logic unit of a FPGA,
> only 4 to 20.

The Lattice isp1048 PLD had a lot more connectivity than a modern FPGA.
This is why a VLIW design on the PLD was possible, but is impossible on an FPGA.
Rick Collins is a clown because he doesn't understand this. He says that a VLIW
is easy on an FPGA, although he has never done this. He's fantasizing.

The strength of an FPGA is that they "are the embodiment of parallel operations."
This has to be loosely-coupled parallelism to avoid the connectivity problem.
This is why all modern FPGA designs are multi-core systems.
John Hart is a clown because he doesn't because he doesn't understand this. He says
that his single-core RACE processor is relevant in modern times, but it isn't.

The MiniForth was pretty awesome in 1995 when it came out.
If I had continued building upon MFX I could have made it successful, at least for a while.
A VLIW processor is obsolete now (this might still be possible in an ASIC, though).

The truth that John Hart dodges is that I did write MFX.
He contributed only bad advice that I ignored (he expected the application programmer
to do the out-of-ordering, but I wrote MFX to do this automatically).
I was being a team player by succeeding at writing MFX despite the abysmally low pay,
lack of health insurance and lack of support (no advice whatsoever on how to do this).
Testra totally betrayed me by refusing to admit that I wrote MFX, telling everybody that
I was a stupid little maintenance programmer who pretends to have written MFX that I used
but that real programmers (John Hart and Steve Brault) actually wrote.
Nobody will ever hire a liar!

Nobody should hire Testra because Tom Hart and John Hart are liars.
The problem is not just that their single-core processor is obsolete in the 21st century,
the problem is that they betrayed their employee in 1995, and continue to do this today.
Nobody will ever agree to be their employee when the result is certain betrayal.

[Jurgen Pitaske]

Hugh, stop accusing others and call them liars without any proof,
and go back into your mental home.
And close the door behind you and lock it.
And throw the key through the window.

If their product is old or new does not matter
- does it do the job and do people buy it.
Customers did this over the last 30 yeears.

Testra is a company successful for 30 years at least now.
Accusing others is just your usual bullshit.

If they did not pay you enough?
Why did you not just leave and get double the salary elswhere.

You should get back into your taxi or drive the tractor. Or plumbing as you said.
This would make sure you do not waste our time here.
I AM PISSED OFF WITH YOUR CONTINUOUS BULLSHIT AND ACCUSATIONS.

[none albert]

In article <474678ef-ab80-411a...@googlegroups.com>,
Hugh Aguilar <hughag...@gmail.com> wrote:
<SNIP>

>Nobody should hire Testra because Tom Hart and John Hart are liars.

Are that the Hart's you have worked for? The Hart's that keep a company
running for decennia while you were plumbing are tax-driving?

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 -

[John Hart]

On Thursday, April 27, 2023 at 7:44:11 PM UTC-7, Hugh Aguilar wrote:
> On Wednesday, April 26, 2023 at 5:59:22 PM UTC-7, John Hart wrote:
> > On Tuesday, April 25, 2023 at 6:23:15 PM UTC-7, Lorem Ipsum wrote:
> > > I can't think of anything that is harder to do in an FPGA than in a CPLD,

<clip>

> > > There is nothing about FPGAs to preclude or make harder parallel operations.

<clip>

> > > Rick C.
> >
> > The basic logic unit of a FPGA is a LUT, typically 4 or 5 inputs.
> > The basic logic unit of a CPGA has 16 to 20 inputs.
> > A 5 input LUT can decode all possible inputs, the basic logic unit of a FPGA,
> > only 4 to 20.
> The Lattice isp1048 PLD had a lot more connectivity than a modern FPGA.

Not true!

> This is why a VLIW design on the PLD was possible, but is impossible on an FPGA.

I don't know what a VLIW is, but I know anything possible on a PLD can be done better on a modern FPGA.
<ad hominem & nonsense clipped>

> A VLIW processor is obsolete now (this might still be possible in an ASIC, though).

Our original MSI LSI based processor (4S32) used in thousands ofTicketMaster terminals,
was a Harvard architecture with a 32 bit instruction (not sure if that qualifies as VLIW),
a 16 bit data path and 4 bit ALU. [An emulation of an Intel 286 (virtual PC) on it would
run a little faster than it. An emulation of a customers 16 bit processor ran 5 times faster.]

The Forth multi-user system we manufactured using the same CPU supported 7 users.
When we moved the design to the PLD ,the instruction width was shrunk to 16 bits, which
I'm sure doesn't qualify as a Very Large Instruction Width. The arithmetic part of the ALU
remained 4 bits but the logic part became 16.

The instruction word for the RACE32 is 18 bits, so it's not a VLIW either,
but the ALU and internal data path have been expanded to 32 bits, enabled by
the fast ripple carry feature of FPGAs.

The power of modern FPGA would blow people's minds, if they understood them.
Advanced supercomputer have tens of thousands of chips with thousands of processes
running in each one with more computing power than a PC. The fear about AAI taking
over the world is based on the reality of what can be done with this power
and how dangerous it would be if abused.

Restrictions won't reduce the danger, they'll make it more dangerous, more concentrated.
The solution to Big Tech having too much power is to empower people. Enable small business
to use robotics and automation to compete. Something like an open source platform programed
in Forth for automation would be the ideal tool to enable it. Focusing on solutions is the
only way out of the mess we're in, Attacks and flame wars are a DEAD END, they accomplish
NOTHING, and the din drowns out rational discourse.

HUGH WROTE MFX, never said he didn't. He was quite creative at the time.

<clip more ad hominem crap>

[Hugh Aguilar]

On Friday, April 28, 2023 at 11:56:23 AM UTC-7, John Hart wrote:
> On Thursday, April 27, 2023 at 7:44:11 PM UTC-7, Hugh Aguilar wrote:
> > On Wednesday, April 26, 2023 at 5:59:22 PM UTC-7, John Hart wrote:
> > > On Tuesday, April 25, 2023 at 6:23:15 PM UTC-7, Lorem Ipsum wrote:
> > > > I can't think of anything that is harder to do in an FPGA than in a CPLD,
> <clip>
> > > > There is nothing about FPGAs to preclude or make harder parallel operations.
> <clip>
> > > > Rick C.
> > >
> > > The basic logic unit of a FPGA is a LUT, typically 4 or 5 inputs.
> > > The basic logic unit of a CPGA has 16 to 20 inputs.
> > > A 5 input LUT can decode all possible inputs, the basic logic unit of a FPGA,
> > > only 4 to 20.
> > The Lattice isp1048 PLD had a lot more connectivity than a modern FPGA.
> Not true!
> > This is why a VLIW design on the PLD was possible, but is impossible on an FPGA.
> I don't know what a VLIW is, but I know anything possible on a PLD can be done better on a modern FPGA.

If you don't know what a VLIW is, then you presumably don't know what out-of-ordering
is either --- out-of-ordering is the distinctive feature of a VLIW.

You didn't know what out-of-ordering was in 1994 either.
You told me to write the assembler with each line representing one opcode, and all
five instructions that would be embedded in that opcode (and would execute
concurrently in a single clock cycle) on that line.
That was stupid!!! I remember at the time being stunned by the stupidity of your advice.
What I did was write the assembler so that the user would write his source-code as if
the instructions were executed sequentially, and my assembler would out-of-order
the instructions to pack them into the opcodes to minimize the number of NOP
instructions that had to be inserted while yet guaranteeing that the program did
the same thing as if the instructions were executed sequentially as they had been
written in the source-code. I got this idea from the Pentium with its U and V pipes.
MFX did the out-of-ordering at compile-time rather than run-time, so that was easier,
but the MiniForth had five instructions executing concurrently whereas the Pentium
only had two instructions executing concurrently (U and V), so that was more difficult.

You aren't any good at computer programming. You didn't understand out-of-ordering
in 1994, and you apparently still don't. All of your advice was stupid. I wrote all of the
code without any help at all, but now you take credit for writing it.

> The power of modern FPGA would blow people's minds, if they understood them.
> Advanced supercomputer have tens of thousands of chips with thousands of processes
> running in each one with more computing power than a PC. The fear about AAI taking
> over the world is based on the reality of what can be done with this power
> and how dangerous it would be if abused.

Only idiots watch the Terminator movies and take that nonsense seriously.
Apparently you are also a fan of the "Groundhog Day" movie.
This is a pathetic life. I recommend that you throw away your DVD player.

> HUGH WROTE MFX, never said he didn't. He was quite creative at the time.

You are lying, of course.
This is the first time that you have ever admitted in public that I wrote MFX.

I remember going to a job interview and the personnel lady called Testra on the
phone, and put it on speaker-phone so I could hear. The person who answered
at Testra identified himself as John Hart. He said that I had done "nothing"
in my time working there, and that I was not eligible for rehire.
Since then, you have claimed that this was actually Tom Hart impersonating you.
Maybe so! It doesn't matter though because you are 100% loyal to Tom Hart, so
when he puts words in your mouth those are your words, because you don't complain.
Note that this was at a time when you were trying to talk me into coming back to
work at Testra, so I was eligible for rehire. I think that your plan was to prevent me
from finding work elsewhere so that low finances would force me to return to Testra.
You didn't expect me to find out about this. I wouldn't have found out except that the
personnel lady put you on speaker phone, but that was unusual. As an example, I applied
at Lockheed Martin because they had a VLIW processor that they were using for
processing radar images. I went through two interviews and everything looked good.
I was told that they needed to verify at Testra, and then they would get back to me.
They got back to me and told me that I was disqualified for any job at Lockheed Martin.
Apparently you knew that Lockheed Martin would pay me more than $10/hour, and that
I wouldn't return to Testra, so you undermined my effort to get ahead in life.

After the incident with the speaker-phone, I never applied for work as a programmer again.
Writing MFX was my claim to fame. I needed that to get a job as a programmer.

Testra began attacking me on comp.lang.forth in 2019.
Tom Hart refused to admit that I wrote MFX (assembler/simulator and Forth cross-compiler).
Now in 2023 you finally admit that I wrote MFX, but you claim that you never
said that I didn't. Bullshit! You have been saying that you and Steve Brault wrote MFX
for the last three decades.

On Friday, September 13, 2019 at 9:08:59 AM UTC-7, Jurgen Pitaske wrote:
> The official answer from Tom Hart, their president,
> who agreed to have his answer to me published on clf:
>
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> [Hugh] wrote our Forth compiler for the processor
> that we implemented in a Lattice PLD.
>
> He did a good job on it,
> we are still using it with a few bug fixes and minor modifications.
>
> He had nothing to do with the processor itself,
> that was all designed by John Hart and Steve Brault.
>
> The PLD version was based upon our original Forth Engine done long before
> we ever ran across Hugh.

Tom Hart is saying that MFX was written long before Testra ever ran across me.
Obviously, the assembler/simulator is an integral part of the MiniForth, so Tom Hart
is saying that I was never anything more than a stupid little maintenance programmer
who used MFX that was written by real programmers before I hired on.
He is effectively accusing me of lying when I say that I wrote MFX.

Tom Hart is giving me credit for writing the interactive Forth compiler. Bullshit!
That was written in MFX after I left. That required all of the assembly-language
to already be done because you can't have an assembler on the MiniForth due
to not being able to write to code-memory. Writing the interactive Forth compiler
would have been trivial because I had already written all of the primitives in
assembly-language. I also wrote the assembler.
When people read Tom Hart's lies they believe that there is no evidence to
indicate that I programmed in assembly-language, much less wrote the assembler.
They believe that I ported figForth over to the MiniForth. This is a lie, and you have
never contradicted your brother --- you have never stood up and told the truth.

Why did Testra attack me on comp.lang.forth with lies and insults?
Tom Hart made this attack on the command of Juergen Pintaske, the MPE salesman.
Apparently you were in negotiation with Stephen Pelc for him to buy the RACE processor,
and you believed that you had to obey Juergen Pintaske's commands to stay on
Stephen Pelc's good side. It is unlikely that Stephen Pelc was going to buy your RACE
processor. He was most likely just tugging your chain for the entertainment value of
getting you to attack your own employee on comp.lang.forth. You think that you can
totally crush me here on comp.lang.forth, but you harm yourself as much or more
than you harm me. Testra won't be considered to be a reputable company any more.
You have more to lose than I do. People who live in glass houses shouldn't throw stones!
Attacking me on comp.lang.forth was a bad idea. Was alcohol involved in this decision?

[Lorem Ipsum]

On Friday, April 28, 2023 at 2:56:23 PM UTC-4, John Hart wrote:
> On Thursday, April 27, 2023 at 7:44:11 PM UTC-7, Hugh Aguilar wrote:
> > On Wednesday, April 26, 2023 at 5:59:22 PM UTC-7, John Hart wrote:
> > > On Tuesday, April 25, 2023 at 6:23:15 PM UTC-7, Lorem Ipsum wrote:
> > > > I can't think of anything that is harder to do in an FPGA than in a CPLD,
> <clip>
> > > > There is nothing about FPGAs to preclude or make harder parallel operations.
> <clip>
> > > > Rick C.
> > >
> > > The basic logic unit of a FPGA is a LUT, typically 4 or 5 inputs.
> > > The basic logic unit of a CPGA has 16 to 20 inputs.
> > > A 5 input LUT can decode all possible inputs, the basic logic unit of a FPGA,
> > > only 4 to 20.
> > The Lattice isp1048 PLD had a lot more connectivity than a modern FPGA.
> Not true!
> > This is why a VLIW design on the PLD was possible, but is impossible on an FPGA.
> I don't know what a VLIW is, but I know anything possible on a PLD can be done better on a modern FPGA.

Hugh won't agree on this, but a VLIW (Very Long Instruction Word) processor has very little encoding of fields, with many control points in the processor having individual bits in the instruction word. This provides tons of flexibility in each instruction, rather than being limited to a fixed instruction set. In particular, this allows the maximum parallelism to be exploited.

TI used "VLIW" in their TMS320C6xxx DSP line, but it's not quite the same thing. They had multiple CPUs in the chip, which all had a core functionality, with enhanced features in a few. They simply aggregated the 32 bit instructions into a 256 bit main instruction word. The earlier versions of the processor were bandwidth limited because of the need for external program storage. Eventually, as semiconductor processing provide more and more, on-chip memory, they could keep all the processors running. They were essentially used with a few doing math operations, while others were DMA engines keeping the data moving. Still, not exactly, VLIW, in the traditional sense.

I worked on attached array processors, which were VLIW in the real sense, with over 100 bits in the ALU control store. There was a separate "storage-move" processor that managed moving the data between main memory, cache and the compute head register file. Lots of ECL gate arrays, and lots of power.

> <ad hominem & nonsense clipped>
> > A VLIW processor is obsolete now (this might still be possible in an ASIC, though).
> Our original MSI LSI based processor (4S32) used in thousands ofTicketMaster terminals,
> was a Harvard architecture with a 32 bit instruction (not sure if that qualifies as VLIW),

That's a standard processor design, I expect, with encoded fields.

> a 16 bit data path and 4 bit ALU. [An emulation of an Intel 286 (virtual PC) on it would
> run a little faster than it. An emulation of a customers 16 bit processor ran 5 times faster.]

Maybe I spoke too soon. To say if it was along the concept of VLIW would require considering what the fields in the instruction were doing. If they mostly directly controlled various functions in the CPU, rather than being encoded, that would be VLIW.

> The Forth multi-user system we manufactured using the same CPU supported 7 users.
> When we moved the design to the PLD ,the instruction width was shrunk to 16 bits, which
> I'm sure doesn't qualify as a Very Large Instruction Width. The arithmetic part of the ALU
> remained 4 bits but the logic part became 16.

It's not the number of bits in the instruction word, really. It's how they are used. If it has to be decoded, that's not VLIW. If individual bits directly control things like a mux select line or the selection of carry, etc, that's VLIW.

> The instruction word for the RACE32 is 18 bits, so it's not a VLIW either,
> but the ALU and internal data path have been expanded to 32 bits, enabled by
> the fast ripple carry feature of FPGAs.
>
> The power of modern FPGA would blow people's minds, if they understood them.
> Advanced supercomputer have tens of thousands of chips with thousands of processes
> running in each one with more computing power than a PC. The fear about AAI taking
> over the world is based on the reality of what can be done with this power
> and how dangerous it would be if abused.
>
> Restrictions won't reduce the danger, they'll make it more dangerous, more concentrated.
> The solution to Big Tech having too much power is to empower people. Enable small business
> to use robotics and automation to compete. Something like an open source platform programed
> in Forth for automation would be the ideal tool to enable it. Focusing on solutions is the
> only way out of the mess we're in, Attacks and flame wars are a DEAD END, they accomplish
> NOTHING, and the din drowns out rational discourse.

What mess??? I must have missed something.

> HUGH WROTE MFX, never said he didn't. He was quite creative at the time.
>
> <clip more ad hominem crap>

Yeah, he's definitely off the deep end these days. He used to be a regular ranter here... I mean, a regular contributor here. But he disappeared for some time. He's not back in full force. He used to go out of his way to argue with people. He seems much more restrained now.

--

Rick C.

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

[Jurgen Pitaske]

>
> Why did Testra attack me on comp.lang.forth with lies and insults?
> Tom Hart made this attack on the command of Juergen Pintaske, the MPE salesman.
> Apparently you were in negotiation with Stephen Pelc for him to buy the RACE processor,
> and you believed that you had to obey Juergen Pintaske's commands to stay on
> Stephen Pelc's good side. It is unlikely that Stephen Pelc was going to buy your RACE
> processor. He was most likely just tugging your chain for the entertainment value of
> getting you to attack your own employee on comp.lang.forth. You think that you can
> totally crush me here on comp.lang.forth, but you harm yourself as much or more
> than you harm me. Testra won't be considered to be a reputable company any more.
> You have more to lose than I do. People who live in glass houses shouldn't throw stones!
> Attacking me on comp.lang.forth was a bad idea. Was alcohol involved in this decision?

TYPICAL HUCK AQUILUX BULLSHIT AGAIN.

He insinuates things that were never planned nor happened,
just to be able to attack people again.
All of these attacked are professionals - in contrast to him and his behaviour here.
And to waste everybody's time.

HE IS INSANE AND PROBABLY A DANGER FOR THE PEOPLE AROUND HIM.

I had just asked Testra to kindly state his activities with Testra
as an answer to all of his accusations here.
- which they did under the condition their email is published in full - which I did.
If there are some differences in perceptions 30 years later - so what.
This is how life works.

[John Hart]

On Friday, April 28, 2023 at 10:41:09 PM UTC-7, Jurgen Pitaske wrote:
> >
> > Why did Testra attack me on comp.lang.forth with lies and insults?

No one from Testra ever attacked anyone on comp.lang.forth
or any other news group ever.

A gifted programmer, with no experience was given a chance,
succeeded and was let go after he finished because there was
nothing for him to do.

> I had just asked Testra to kindly state his activities with Testra

Which indicated he was a creative individual and like many creative
individuals, might be difficult to work with. A truth that's easily verified
by reading posts on this and many other tech newsgroups.

Not referring to anyone specific, some people not only burn their bridges
they spend years taking the foundation down to bedrock with a jackhammer
until no evidence of what they accomplished remains.

Flame wars are not only counterproductive they're destructive. Most
people, if they knew then what they know now, would have done things
differently. It's also true that if wishes were horses, beggers would ride.

Learning from past mistakes is good, getting mired in them is not.

My purpose for writing is NOT to get sucked into a flame war,
it's to have a discussion about Forth being the ideal language for a
Reconfigurable Architecture Computation Engine, specifically the
RACE32, which we are in the process of completing,

A thousand such processors could run on one of the new FPGA chips,
but the main applications, automation and robotics, would require
only one and run on a low cost device.
jrh

[John Hart]

On Friday, April 28, 2023 at 5:06:51 PM UTC-7, Lorem Ipsum wrote:
> On Friday, April 28, 2023 at 2:56:23 PM UTC-4, John Hart wrote:
> > On Thursday, April 27, 2023 at 7:44:11 PM UTC-7, Hugh Aguilar wrote:
> > > On Wednesday, April 26, 2023 at 5:59:22 PM UTC-7, John Hart wrote:
> > > > On Tuesday, April 25, 2023 at 6:23:15 PM UTC-7, Lorem Ipsum wrote:
> > > > > I can't think of anything that is harder to do in an FPGA than in a CPLD,
> > > > ><clip>

> What mess??? I must have missed something.

> Rick C.
Not your fault if you still rely on MSM for your news.
America is in sharp decline on many fronts and MSM has been working overtime
hiding it. The parts of our social economic system are strongly linked and
a series of errors by the current administration, as serious as the Titanic
hittting an iceberg, have occured. The only solution is to get productivity
growing faster than debt to prevent runaway inflation, and that's going
to require an autiomation revolution at the roots. The concentration of
wealth by the Elite, not only stifles innovation it's extremely dangerous.
After all, power corrupts and absolute power corrupts absolutely.

[Jurgen Pitaske]

A great post - Thank You

[Lorem Ipsum]

Got it. I completely understand now. Thanks

--

Rick C.

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

[Hugh Aguilar]

On Friday, April 28, 2023 at 11:47:36 PM UTC-7, John Hart wrote:
> On Friday, April 28, 2023 at 10:41:09 PM UTC-7, Jurgen Pitaske wrote:
> > >
> > > Why did Testra attack me on comp.lang.forth with lies and insults?
> No one from Testra ever attacked anyone on comp.lang.forth
> or any other news group ever.

Bullshit!
This entire thread was an unprovoked attack on me:
https://groups.google.com/g/comp.lang.forth/c/wydQr643gX0

Tom Hart was totally lying:
> I let him go myself,
> after I had given him a project to write a DXF converter to HPGL code.
> He would not take any direction.
> I scrapped the project.

I never even heard of HPGL before this attack. There was no HPGL project.
Also, I never got any direction in any of my work.
When I wrote the DXF to GCODE converter nobody told me about how
Bezier Splines might work. I didn't know about Bezier Splines, and I assume
that the reason I wasn't told about Bezier Splines is that Tom and John Hart
don't know about them either. Tom Hart would just angrily tell me:
"Just make a smooth line through all the tiny line segments!"
There was just a mish-mash of tiny line segments ranging from 1/1000 of an inch
to 20/1000 of an inch, and some longer. They pointed in every which direction. Some
weren't touching any other line segment and some touched other line segments.
I had no idea how to make a smooth line through this mess. I wished that I did
have some direction, but I never did. I wished that I had mind-reading ability
so that I could know what image the artist had intended with this mish-mash.
Tom Hart says that I'm too stupid to write a data-conversion program.
This isn't true. I was converting DXF code to GCODE within a couple of weeks
of starting the project. The problem was that the result was a mess.
When I started the project I was told that this was a simple data-conversion
program, so I felt confident that I could finish in a few weeks. If I had been told
that I had to make a smooth line through a big mess of tiny line-segments,
I would have refused the job. If I had been told that I needed Bezier Splines
I would have refused the job because I don't know anything about the subject.
(This is where the comp.lang.forth trolls can spring into action and say that
they could easily implement Bezier Splines, so they get to be big internet experts
without writing any code, as usual).

Tom Hart was totally lying:
> [Hugh] had nothing to do with the processor itself,

> that was all designed by John Hart and Steve Brault.
>
> The PLD version was based upon our original Forth Engine done long before
> we ever ran across Hugh.

The original Forth Engine was a bit-slice processor.
This is unrelated to the MiniForth that was a VLIW processor.
Tom Hart is saying that MFX was written for the bit-slice processor and then
was used on the MiniForth. Bullshit! I wrote MFX for the MiniForth (MFX means
Mini Forth Xcompiler). I never saw any of the code from the original Forth Engine.
All of that was written by John Perona who later wrote Multi-Edit. Even if there
had been some similarity between the original Forth Engine and the MiniForth,
I still wouldn't have looked at John Perona's code because I never look at other
people's code (that is like peering through a bedroom window to look at your
neighbor's wife). Also, as a practical matter John Perona is a typical C programmer
who writes multi-page functions. He doesn't factor code at all.

Testra was originally called Hartronics and they advertised their "Forth Engine"
in Forth Dimensions, in case anybody cares (I don't).

It was obvious that Juergen Pintaske wanted to denounce me on comp.lang.forth,
by saying that I am lying about writing MFX at Testra. Tom Hart totally complied by
providing Juergen Pintaske with support for this attack. All of Juergen Pintaske's
attacks on me over the last four years have been based on him obtaining 100%
support from Tom Hart.
It is very disingenuous for John Hart to now say:

> No one from Testra ever attacked anyone on comp.lang.forth
> or any other news group ever.

Bullshit! You could have ignored Juergen Pintaske. Everybody else in the world does!
Instead you provided Juergen Pintaske with 100% support for attacking me.
Juergen Pintaske is now Testra's mouthpiece, and he has Tom Hart's support in this.

> Not referring to anyone specific, some people not only burn their bridges
> they spend years taking the foundation down to bedrock with a jackhammer
> until no evidence of what they accomplished remains.

It was in the 1990s, less than five years after I left Testra, when I heard John Hart
(possibly Tom Hart doing an impersonation) say on speaker-phone that I had
accomplished "nothing" and that I was not eligible for rehire. Presumably Testra had
been saying this starting immediately after I left Testra but it was a few years later
when I caught them at this. So, it didn't take Tom Hart long to burn his bridge with me,
and jackhammer the foundation, to ensure that no evidence of accomplishment remains.
Tom Hart cares about loyalty! He expects employees to remain employed forever,
never asking for a raise or health insurance or anything else. Loyalty is a one-way street;
Tom Hart has no sense of loyalty to his employees and will attack them in public.

Why didn't Testra just tell me when I left that leaving was an act of disloyalty
and that I would never get a reference? I made a fool out of myself by going to
job interviews, such as at Lockheed Martin, and saying that I wrote MFX at Testra.
Most likely, Testra wanted me to go to these job interviews and describe MFX,
not for my benefit, but just as an advertisement for Testra's MiniForth processor.
They may have been hoping that Lockheed Martin would buy the MiniForth so
they could become wealthy, but they had no way to get Lockheed Martin's attention.
You can't just show up in the lobby of Lockheed Martin and tell the receptionist:
"Hi! I've got a super-awesome processor! Would you like to buy it?"
They may have believed (correctly) that for me to go to a job interview at
Lockheed Martin and describe MFX would be the only way that Lockheed Martin
would find out about the MiniForth --- but they would pull the rug out from under me
by telling Lockheed Martin that they wrote MFX --- they would explain to
Lockheed Martin that they are geniuses who deserve to get rich!

[Jurgen Pitaske]

WHAT A MENTAL DESASTER AGAIN.

Everybody is a liar - which automatically leads to
HUGH AGUILAR IS an AGUILIAR as he is part of everybody.
GO BACK TO YOUR CAGE AND BARK OR NOT.

Another made up piece of lies - just to make you feel good.

I did my job at MPE as consultant,
which triggered tmy FORTH BOOKSHELF on amazon
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM%3Fref=dbs_a_mng_rwt_scns_share
I convinced Steve to do the 1802 in FPGA and the FIG-Forth that goees with it on github.
And he did as well the MISC PROCESSOR I HAD INITIATED in FPGA plus a Forth that goes with it.
What have you contributed over the last 30 years
- except of often dayly rants and
accusations of probably everybody here.

[Jurgen Pitaske]

LIAR LIAR LIAR - YOU ARE DOING WELL.
To state that my letter to Testra and the kind answer from there was started without reason
is the biggest lie you ever told.

You have attacked me over the last 10 years for no real reason
- it is all here on CLF so you can check
for no real reason.
So I wondered what Testra would say about you,
and it ended up in the probably most read post of CLF with about 4400 reads now.
https://groups.google.com/g/comp.lang.forth/c/wydQr643gX0
It will be 4444 soon -
You cannot get closer to fours.
Have a nice day,
and May The Fours Be With You.

[Jurgen Pitaske]

... and 1444 views here now

[Jurgen Pitaske]

4444 views achieved. on 30 fourth month of the year 2023