Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #48971 > unrolled thread

Forth coding style vs "Algol et al" coding style

Started byfoxaudioresearch@gmail.com
First post2016-07-08 17:44 -0700
Last post2016-07-11 08:03 -0700
Articles 20 on this page of 67 — 18 participants

Back to article view | Back to comp.lang.forth

Contents

  Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-08 17:44 -0700
    Re: Forth coding style vs "Algol et al" coding style "WJ" <w_a_x_man@yahoo.com> - 2016-07-09 04:27 +0000
    Re: Forth coding style vs "Algol et al" coding style humptydumpty <ouatubi@gmail.com> - 2016-07-09 10:30 -0700
      Re: Forth coding style vs "Algol et al" coding style Julian Fondren <julian.fondren@gmail.com> - 2016-07-09 21:56 -0700
        Re: Forth coding style vs "Algol et al" coding style mhx@iae.nl - 2016-07-10 00:30 -0700
          Re: Forth coding style vs "Algol et al" coding style mhx@iae.nl - 2016-07-10 00:34 -0700
            Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-10 09:10 -0700
        Re: Forth coding style vs "Algol et al" coding style endlessboomcapitalism@gmail.com - 2016-07-12 18:55 -0700
    Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-10 01:39 -0700
      Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-10 08:50 -0700
        Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-10 15:00 -0700
          Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-10 22:53 -0400
            Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 01:59 -0700
              Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 09:44 -0400
                Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:51 -0700
                  Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 15:26 -0400
                    Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-12 15:18 -0700
                  Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-25 19:56 -0700
                    Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 23:13 -0400
                      Re: Forth coding style vs "Algol et al" coding style jim.brakefield@ieee.org - 2016-07-26 07:34 -0700
                        Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 11:23 -0400
                          Re: Forth coding style vs "Algol et al" coding style jim.brakefield@ieee.org - 2016-07-26 13:18 -0700
                            Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 18:14 -0400
                      Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:43 -0700
                        Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:24 -0400
                    Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:46 -0700
                      Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:26 -0400
                    Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:53 -0700
                      Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-27 08:32 -0700
                        Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-27 09:04 -0700
                          Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-28 02:05 -0700
                            Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-28 06:27 -0700
                              Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-29 03:01 -0700
                                Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-30 02:28 -0400
              Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 13:05 -0400
                Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:47 -0700
          Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 08:50 -0500
            Re: Forth coding style vs "Algol et al" coding style Michael Barry <barrym95838@yahoo.com> - 2016-07-11 08:23 -0700
              Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 11:48 -0500
                Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 12:16 -0500
                  Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:38 -0700
                    Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 13:32 -0500
                  Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 12:45 -0500
                    Re: Forth coding style vs "Algol et al" coding style Brad Eckert <hwfwguy@gmail.com> - 2016-07-11 11:49 -0700
                      Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-12 05:02 -0500
                Re: Forth coding style vs "Algol et al" coding style Michael Barry <barrym95838@yahoo.com> - 2016-07-11 14:22 -0700
                  Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 16:31 -0500
                  Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-12 15:31 -0400
                    Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:55 -0700
                      Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:48 -0400
                        Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-08-10 01:54 -0700
              Re: Forth coding style vs "Algol et al" coding style Howerd <howerdo@yahoo.co.uk> - 2016-07-11 11:58 -0700
            Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:59 -0700
              Re: Forth coding style vs "Algol et al" coding style Bernd Paysan <bernd.paysan@gmx.de> - 2016-07-26 00:40 +0000
                Re: Forth coding style vs "Algol et al" coding style "Elizabeth D. Rather" <erather@forth.com> - 2016-07-25 21:16 -1000
                Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-26 03:34 -0500
                Re: Forth coding style vs "Algol et al" coding style anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-26 16:51 +0000
                  Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 13:51 -0400
              Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:50 -0400
              Re: Forth coding style vs "Algol et al" coding style Brad Eckert <hwfwguy@gmail.com> - 2016-07-26 16:32 -0700
                Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:19 -0400
                  Re: Forth coding style vs "Algol et al" coding style "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 09:05 -1000
          Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:51 -0700
            Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-14 03:34 -0700
              Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:51 -0400
        Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 01:56 -0700
          Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-11 08:03 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#48971 — Forth coding style vs "Algol et al" coding style

Fromfoxaudioresearch@gmail.com
Date2016-07-08 17:44 -0700
SubjectForth coding style vs "Algol et al" coding style
Message-ID<3a7d6348-9545-4fdc-b990-cefcb0b7f0e6@googlegroups.com>
While learning about the TI-99 a little more I took a read through some docs on
the MSP430 and found a familiar looking assembly language.

In a doc "TI called MSP430 competitive benchmarks" I found some C language
examples and as I looked at one I thought about how would one do this is
Forth.  I have always been fascinated (envious too) by the way some Forth
coders can really exploit the alternate paradigm that Forth provides.


Here is the C program:
\ ******************************************************************************
\ *
\ * Name : 8-bit 2-dim Matrix 
\ * Purpose : Benchmark copying 8-bit values.
\ *
\ *****************************************************************************/
\ typedef unsigned char UInt8;
\ const UInt8 m1[16][4] = {
\                            {0x12, 0x56, 0x90, 0x34},
\                            {0x78, 0x12, 0x56, 0x90},
\                            {0x34, 0x78, 0x12, 0x56},
\                            {0x90, 0x34, 0x78, 0x12},
\                            {0x12, 0x56, 0x90, 0x34},
\                            {0x78, 0x12, 0x56, 0x90},
\                            {0x34, 0x78, 0x12, 0x56},
\                            {0x90, 0x34, 0x78, 0x12},
\                            {0x12, 0x56, 0x90, 0x34},
\                            {0x78, 0x12, 0x56, 0x90},
\                            {0x34, 0x78, 0x12, 0x56},
\                            {0x90, 0x34, 0x78, 0x12},
\                            {0x12, 0x56, 0x90, 0x34},
\                            {0x78, 0x12, 0x56, 0x90},
\                            {0x34, 0x78, 0x12, 0x56},
\                            {0x90, 0x34, 0x78, 0x12}
\                                                     };
\ void  main(void)
\ {
\      int i,j;
\      volatile UInt8 m2[16][4], m3[16][4];
\      for(i=0;i<16;i++)
\      {
\         for(j=0;j<4;j++)
\         {
\            m2[i][j]=m1[i][j];
\            m3[i][j]=m2[i][j];
\         }
\      }
\      return;
\ }

And here is my "vanilla" version attempting to emulate the the C coding style
creating a very simple and at the same time sub-optimal program in Forth.

\ Forth Equivalent written something like C
\ Yes, I know it uses static allocations which is typical Forth

create m1   HEX  12 c, 56 c, 90 c, 34  c,
                 78 c, 12 c, 56 c, 90  c,
                 34 c, 78 c, 12 c, 56  c,
                 90 c, 34 c, 78 c, 12  c,
                 12 c, 56 c, 90 c, 34  c,
                 78 c, 12 c, 56 c, 90  c,
                 34 c, 78 c, 12 c, 56  c,
                 90 c, 34 c, 78 c, 12  c,
                 12 c, 56 c, 90 c, 34  c,
                 78 c, 12 c, 56 c, 90  c,
                 34 c, 78 c, 12 c, 56  c,
                 90 c, 34 c, 78 c, 12  c,
                 12 c, 56 c, 90 c, 34  c,
                 78 c, 12 c, 56 c, 90  c,
                 34 c, 78 c, 12 c, 56  c,
                 90 c, 34 c, 78 c, 12  c,

DECIMAL
  4 16 * constant 4x16

  4x16 buffer: m2
  4x16 buffer: m3

\ ==================================================================
\ forth needs byte matrix operators but they are simple

: []     ( x y addr -- addr' ) + swap 4 * + ;
: []c@   ( x y addr -- char )  [] c@ ;
: []c!   ( char x y addr -- )  [] c! ;

: main()
            16 0 do
               4 0 do
                   j i m1 []c@  j i m2 []c!
                   j i m2 []c@  j i m3 []c!
               loop
            loop ;


However of course in Forth one would just do:

: fmain
            m1 m2 4x16 cmove
            m2 m3 4x16 cmove ;

The speed improvement on my 16bit ITC system is 7.8X vs the C style version.


Does anyone have examples of code where they can contrast the conventional method versus Forth?

BF

[toc] | [next] | [standalone]

#48972

From"WJ" <w_a_x_man@yahoo.com>
Date2016-07-09 04:27 +0000
Message-ID<nlpug1$qe4$1@dont-email.me>
In reply to#48971
foxaudioresearch@gmail.com wrote:

> While learning about the TI-99 a little more I took a read through some docs on
> the MSP430 and found a familiar looking assembly language.
> 
> In a doc "TI called MSP430 competitive benchmarks" I found some C language
> examples and as I looked at one I thought about how would one do this is
> Forth.  I have always been fascinated (envious too) by the way some Forth
> coders can really exploit the alternate paradigm that Forth provides.
> 
> 
> Here is the C program:
> \ ******************************************************************************
> \ *
> \ * Name : 8-bit 2-dim Matrix 
> \ * Purpose : Benchmark copying 8-bit values.
> \ *
> \ *****************************************************************************/
> \ typedef unsigned char UInt8;
> \ const UInt8 m1[16][4] = {
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12}
> \                                                     };
> \ void  main(void)
> \ {
> \      int i,j;
> \      volatile UInt8 m2[16][4], m3[16][4];
> \      for(i=0;i<16;i++)
> \      {
> \         for(j=0;j<4;j++)
> \         {
> \            m2[i][j]=m1[i][j];
> \            m3[i][j]=m2[i][j];
> \         }
> \      }
> \      return;
> \ }
> 
> And here is my "vanilla" version attempting to emulate the the C coding style
> creating a very simple and at the same time sub-optimal program in Forth.
> 
> \ Forth Equivalent written something like C
> \ Yes, I know it uses static allocations which is typical Forth
> 
> create m1   HEX  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
> 
> DECIMAL
>   4 16 * constant 4x16
> 
>   4x16 buffer: m2
>   4x16 buffer: m3
> 
> \ ==================================================================
> \ forth needs byte matrix operators but they are simple
> 
> : []     ( x y addr -- addr' ) + swap 4 * + ;
> : []c@   ( x y addr -- char )  [] c@ ;
> : []c!   ( char x y addr -- )  [] c! ;
> 
> : main()
>             16 0 do
>                4 0 do
>                    j i m1 []c@  j i m2 []c!
>                    j i m2 []c@  j i m3 []c!
>                loop
>             loop ;
> 
> 
> However of course in Forth one would just do:
> 
> : fmain
>             m1 m2 4x16 cmove
>             m2 m3 4x16 cmove ;
> 
> The speed improvement on my 16bit ITC system is 7.8X vs the C style version.

OCaml:

#load "bigarray.cma" ;;
open Bigarray ;;

let m1 =
  Array2.of_array int8_unsigned c_layout [|
    [|0x12; 0x56; 0x90; 0x34|];
    [|0x78; 0x12; 0x56; 0x90|];
    [|0x34; 0x78; 0x12; 0x56|];
    [|0x90; 0x34; 0x78; 0x12|];
    [|0x12; 0x56; 0x90; 0x34|];
    [|0x78; 0x12; 0x56; 0x90|];
    [|0x34; 0x78; 0x12; 0x56|];
    [|0x90; 0x34; 0x78; 0x12|];
    [|0x12; 0x56; 0x90; 0x34|];
    [|0x78; 0x12; 0x56; 0x90|];
    [|0x34; 0x78; 0x12; 0x56|];
    [|0x90; 0x34; 0x78; 0x12|];
    [|0x12; 0x56; 0x90; 0x34|];
    [|0x78; 0x12; 0x56; 0x90|];
    [|0x34; 0x78; 0x12; 0x56|];
    [|0x90; 0x34; 0x78; 0x12|]|] ;;

let [| m2; m3 |] =
  Array.init 2 (fun _ -> Array2.create int8_unsigned Bigarray.c_layout 16 4);;

(* Copy the matrix. *)
Array2.blit m1 m2 ;;
Array2.blit m1 m3 ;;

(*  Make sure copying was done correctly.  *)
for i = 0 to 3 do
  Printf.printf "%02x " m2.{15,i}
done ;;

90 34 78 12

-- 
Goyim were born only to serve us....  They will work, they will plow, they will
reap. We will sit like an effendi and eat. --- Rabbi Ovadia Yosef
web.archive.org/web/20101020044210/http://www.jpost.com/JewishWorld/JewishNews/Article.aspx?id=191782
archive.org/download/DavidDuke_videos/TopRabbiExposesJewishRacism-cybsdwjezqi.ogv

[toc] | [prev] | [next] | [standalone]

#48991

Fromhumptydumpty <ouatubi@gmail.com>
Date2016-07-09 10:30 -0700
Message-ID<04aa89fb-310b-466e-98ef-f14fc1fa1cca@googlegroups.com>
In reply to#48971
On Saturday, July 9, 2016 at 3:44:29 AM UTC+3, foxaudio...@gmail.com wrote:
> While learning about the TI-99 a little more I took a read through some docs on
> the MSP430 and found a familiar looking assembly language.
> 
> In a doc "TI called MSP430 competitive benchmarks" I found some C language
> examples and as I looked at one I thought about how would one do this is
> Forth.  I have always been fascinated (envious too) by the way some Forth
> coders can really exploit the alternate paradigm that Forth provides.
> 
> 
> Here is the C program:
> \ ******************************************************************************
> \ *
> \ * Name : 8-bit 2-dim Matrix 
> \ * Purpose : Benchmark copying 8-bit values.
> \ *
> \ *****************************************************************************/
> \ typedef unsigned char UInt8;
> \ const UInt8 m1[16][4] = {
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12}
> \                                                     };
> \ void  main(void)
> \ {
> \      int i,j;
> \      volatile UInt8 m2[16][4], m3[16][4];
> \      for(i=0;i<16;i++)
> \      {
> \         for(j=0;j<4;j++)
> \         {
> \            m2[i][j]=m1[i][j];
> \            m3[i][j]=m2[i][j];
> \         }
> \      }
> \      return;
> \ }
> 
> And here is my "vanilla" version attempting to emulate the the C coding style
> creating a very simple and at the same time sub-optimal program in Forth.
> 
> \ Forth Equivalent written something like C
> \ Yes, I know it uses static allocations which is typical Forth
> 
> create m1   HEX  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
> 
> DECIMAL
>   4 16 * constant 4x16
> 
>   4x16 buffer: m2
>   4x16 buffer: m3
> 
> \ ==================================================================
> \ forth needs byte matrix operators but they are simple
> 
> : []     ( x y addr -- addr' ) + swap 4 * + ;
> : []c@   ( x y addr -- char )  [] c@ ;
> : []c!   ( char x y addr -- )  [] c! ;
> 
> : main()
>             16 0 do
>                4 0 do
>                    j i m1 []c@  j i m2 []c!
>                    j i m2 []c@  j i m3 []c!
>                loop
>             loop ;
> 
> 
> However of course in Forth one would just do:
> 
> : fmain
>             m1 m2 4x16 cmove
>             m2 m3 4x16 cmove ;
> 
> The speed improvement on my 16bit ITC system is 7.8X vs the C style version.
> 
> 
> Does anyone have examples of code where they can contrast the conventional method versus Forth?
> 
> BF

Hi!

Just for fun (&untested):

: x  ( m3 m1 m2 -- 1+m3 1+m1 1+m2 )  over c@ over c! rot over c@ over c! 1+ rot 1+ rot 1+ ;
: 8x ( m3 m1 m2 -- 8+m3 8+m1 8+m2 )  x x x x x x x x ;
: fmain  ( m3 m1 m2 -- )  8x 8x 8x 8x 8x 8x 8x 8x drop drop drop ;

Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

#48996

FromJulian Fondren <julian.fondren@gmail.com>
Date2016-07-09 21:56 -0700
Message-ID<9d82a082-5885-4918-85a9-9de107fa1b7c@googlegroups.com>
In reply to#48991
On Saturday, July 9, 2016 at 12:30:37 PM UTC-5, humptydumpty wrote:
> 
> : x  ( m3 m1 m2 -- 1+m3 1+m1 1+m2 )  over c@ over c! rot over c@ over c! 1+ rot 1+ rot 1+ ;
> : 8x ( m3 m1 m2 -- 8+m3 8+m1 8+m2 )  x x x x x x x x ;
> : fmain  ( m3 m1 m2 -- )  8x 8x 8x 8x 8x 8x 8x 8x drop drop drop ;
> 

  : x ... ;
  : repeat ( xt n -- )  0 ?do dup compile, loop drop ;
  : fmain  ( m3 m1 m2 -- )  [ ' x 64 repeat ] 3drop ;


-- Julian

[toc] | [prev] | [next] | [standalone]

#49001

Frommhx@iae.nl
Date2016-07-10 00:30 -0700
Message-ID<4c37b670-139c-4c6e-bd5d-efc8661822e5@googlegroups.com>
In reply to#48996
On Sunday, July 10, 2016 at 6:56:16 AM UTC+2, Julian Fondren wrote:
> On Saturday, July 9, 2016 at 12:30:37 PM UTC-5, humptydumpty wrote:
> > 
> > : x  ( m3 m1 m2 -- 1+m3 1+m1 1+m2 )  over c@ over c! rot over c@ over c! 1+ rot 1+ rot 1+ ;
> > : 8x ( m3 m1 m2 -- 8+m3 8+m1 8+m2 )  x x x x x x x x ;
> > : fmain  ( m3 m1 m2 -- )  8x 8x 8x 8x 8x 8x 8x 8x drop drop drop ;
> > 
> 
>   : x ... ;
>   : repeat ( xt n -- )  0 ?do dup compile, loop drop ;
>   : fmain  ( m3 m1 m2 -- )  [ ' x 64 repeat ] 3drop ;
> 
> 
> -- Julian

Quite a bandwidth on this simple thing,
between 50 ms and 8 seconds ...
( Note: I didn't verify the copies. )

-marcel

ANEW -cmover

#10000000 VALUE #num

\ ******************************************************************************
\ *
\ * Name : 8-bit 2-dim Matrix 
\ * Purpose : Benchmark copying 8-bit values.
\ *
\ *****************************************************************************/
\ typedef unsigned char UInt8;
\ const UInt8 m1[16][4] = {
\                            {0x12, 0x56, 0x90, 0x34},
\                            {0x78, 0x12, 0x56, 0x90},
\                            {0x34, 0x78, 0x12, 0x56},
\                            {0x90, 0x34, 0x78, 0x12},
\                            {0x12, 0x56, 0x90, 0x34},
\                            {0x78, 0x12, 0x56, 0x90},
\                            {0x34, 0x78, 0x12, 0x56},
\                            {0x90, 0x34, 0x78, 0x12},
\                            {0x12, 0x56, 0x90, 0x34},
\                            {0x78, 0x12, 0x56, 0x90},
\                            {0x34, 0x78, 0x12, 0x56},
\                            {0x90, 0x34, 0x78, 0x12},
\                            {0x12, 0x56, 0x90, 0x34},
\                            {0x78, 0x12, 0x56, 0x90},
\                            {0x34, 0x78, 0x12, 0x56},
\                            {0x90, 0x34, 0x78, 0x12}
\                                                     };
\ void  main(void)
\ {
\      int i,j;
\      volatile UInt8 m2[16][4], m3[16][4];
\      for(i=0;i<16;i++)
\      {
\         for(j=0;j<4;j++)
\         {
\            m2[i][j]=m1[i][j];
\            m3[i][j]=m2[i][j];
\         }
\      }
\      return;
\ }

\ Forth Equivalent written something like C

create m1   HEX  12 c, 56 c, 90 c, 34  c,
                 78 c, 12 c, 56 c, 90  c,
                 34 c, 78 c, 12 c, 56  c,
                 90 c, 34 c, 78 c, 12  c,
                 12 c, 56 c, 90 c, 34  c,
                 78 c, 12 c, 56 c, 90  c,
                 34 c, 78 c, 12 c, 56  c,
                 90 c, 34 c, 78 c, 12  c,
                 12 c, 56 c, 90 c, 34  c,
                 78 c, 12 c, 56 c, 90  c,
                 34 c, 78 c, 12 c, 56  c,
                 90 c, 34 c, 78 c, 12  c,
                 12 c, 56 c, 90 c, 34  c,
                 78 c, 12 c, 56 c, 90  c,
                 34 c, 78 c, 12 c, 56  c,
                 90 c, 34 c, 78 c, 12  c,
DECIMAL

: BUFFER: ( n "name" -- )
    CREATE  ALLOT ;

  4 16 * constant 4x16
  4x16 buffer: m2
  4x16 buffer: m3

\ ==================================================================
: []     ( x y addr -- addr' ) + swap 4 * + ;
: []c@   ( x y addr -- char )  [] c@ ;
: []c!   ( char x y addr -- )  [] c! ;

\ Brian Fox
: fmain1 ( -- )
	CR ." fmain1 : " TIMER-RESET #num 0 DO
	#16 0 do
               #4 0 do
                     j i m1 []c@  j i m2 []c!
                     j i m2 []c@  j i m3 []c!
                  loop
               loop 
	LOOP .ELAPSED ;

: fmain2 ( -- )
	CR ." fmain2 : " TIMER-RESET #num 0 DO
	m1 m2 4x16 cmove
	m2 m3 4x16 cmove 
	LOOP .ELAPSED ;

\ HumptyDumpty
: x  ( m3 m1 m2 -- 1+m3 1+m1 1+m2 )  
	over c@ over c!   
	rot 
	over c@ over c! 
	1+ rot 1+ rot 1+ ;
	
: 8x ( m3 m1 m2 -- 8+m3 8+m1 8+m2 )  x x x x x x x x ;
: fmain3  ( -- )  
	CR ." fmain3 : " TIMER-RESET #num 0 DO
	m3 m2 m1  8x 8x 8x 8x 8x 8x 8x 8x  3drop
	LOOP .ELAPSED ;

\ Julian Fondren
: repeat ( xt n -- )  0 ?do dup compile, loop drop ;
: fmain4  ( -- )  
	CR ." fmain4 : " TIMER-RESET #num 0 DO
	m3 m1 m2 [ ' x #64 REPEAT ] 3drop 
	LOOP .ELAPSED ;

: repeat2 ( xt n -- )  0 ?DO dup compile, LOOP drop ; IMMEDIATE
: fmain5  ( -- )  
	CR ." fmain5 : " TIMER-RESET #num 0 DO
	m3 m1 m2 [ ' x #64 ] REPEAT2 3drop 
	LOOP .ELAPSED ;

\ Baden' macro's
: fmain6  ( -- )  
	CR ." fmain6 : " TIMER-RESET #num 0 DO
	m3 m1 m2 [ #64 0 ] LOOP[ x ] 3drop 
	LOOP .ELAPSED ;

: y  ( m3 m1 m2 -- 8+m3 8+m1 8+m2 )  
	over 2@ 2 pick 2!   
	rot 
	over 2@ 2 pick 2! 
	CELL+ CELL+ rot CELL+ CELL+ rot CELL+ CELL+ ;

: fmain7  ( -- )  
	CR ." fmain7 : " TIMER-RESET #num 0 DO
	m3 m1 m2 y y y y 3drop 
	LOOP .ELAPSED ;

: fmain8 ( -- ) 
	CR ." fmain8 : " TIMER-RESET #num 0 DO
	  m1      d@ 2DUP m2      d!  m3      d!
	  m1 16 + d@ 2DUP m2 16 + d!  m3 16 + d!
	  m1 32 + d@ 2DUP m2 32 + d!  m3 32 + d!
	  m1 48 + d@ 2DUP m2 48 + d!  m3 48 + d!
	LOOP .ELAPSED ;
	
fmain1 fmain2 fmain3 fmain4 fmain5 fmain6 fmain7 fmain8

\ fmain1 : 4.271 seconds elapsed.
\ fmain2 : 0.666 seconds elapsed.
\ fmain3 : 1.075 seconds elapsed.
\ fmain4 : 7.557 seconds elapsed.
\ fmain5 : 4.779 seconds elapsed.
\ fmain6 : 0.398 seconds elapsed.
\ fmain7 : 0.225 seconds elapsed.
\ fmain8 : 0.053 seconds elapsed. ok


-marcel

[toc] | [prev] | [next] | [standalone]

#49002

Frommhx@iae.nl
Date2016-07-10 00:34 -0700
Message-ID<4bf5f62b-58b2-4f55-9ec8-492c940dfc0f@googlegroups.com>
In reply to#49001
On Sunday, July 10, 2016 at 9:30:24 AM UTC+2, m...@iae.nl wrote:
[..] 	
> fmain1 fmain2 fmain3 fmain4 fmain5 fmain6 fmain7 fmain8
> 
> \ fmain1 : 4.271 seconds elapsed.
> \ fmain2 : 0.666 seconds elapsed.
> \ fmain3 : 1.075 seconds elapsed.
> \ fmain4 : 7.557 seconds elapsed.
> \ fmain5 : 4.779 seconds elapsed.
> \ fmain6 : 0.398 seconds elapsed.
> \ fmain7 : 0.225 seconds elapsed.
> \ fmain8 : 0.053 seconds elapsed. ok

Here are the results when I disable the CPU 
power-saving modes:

FORTH> in
Redefining repeat
fmain1 : 1.633 seconds elapsed.
fmain2 : 0.372 seconds elapsed.
fmain3 : 0.328 seconds elapsed.
fmain4 : 2.712 seconds elapsed.
fmain5 : 2.537 seconds elapsed.
fmain6 : 0.330 seconds elapsed.
fmain7 : 0.185 seconds elapsed.
fmain8 : 0.043 seconds elapsed. ok

Apparently I need faster memory.

-marcel

[toc] | [prev] | [next] | [standalone]

#49014

Fromfoxaudioresearch@gmail.com
Date2016-07-10 09:10 -0700
Message-ID<5d1e7fd9-1bac-4b50-93e4-06be3011e342@googlegroups.com>
In reply to#49002
Thanks Marcel for this analysis.

This is very cool.

B

[toc] | [prev] | [next] | [standalone]

#49099

Fromendlessboomcapitalism@gmail.com
Date2016-07-12 18:55 -0700
Message-ID<e525cfdc-80e6-498e-89f5-fafd436213de@googlegroups.com>
In reply to#48996
On Sunday, July 10, 2016 at 12:56:16 AM UTC-4, Julian Fondren wrote:
> On Saturday, July 9, 2016 at 12:30:37 PM UTC-5, humptydumpty wrote:
> > 
> > : x  ( m3 m1 m2 -- 1+m3 1+m1 1+m2 )  over c@ over c! rot over c@ over c! 1+ rot 1+ rot 1+ ;
> > : 8x ( m3 m1 m2 -- 8+m3 8+m1 8+m2 )  x x x x x x x x ;
> > : fmain  ( m3 m1 m2 -- )  8x 8x 8x 8x 8x 8x 8x 8x drop drop drop ;
> > 
> 
>   : x ... ;
>   : repeat ( xt n -- )  0 ?do dup compile, loop drop ;
>   : fmain  ( m3 m1 m2 -- )  [ ' x 64 repeat ] 3drop ;
> 
> 
> -- Julian

winner!

[toc] | [prev] | [next] | [standalone]

#49005

FromMark Wills <markwills1970@gmail.com>
Date2016-07-10 01:39 -0700
Message-ID<973598e9-c320-4f42-9ad0-5bdf5bfe11a4@googlegroups.com>
In reply to#48971
On Saturday, 9 July 2016 01:44:29 UTC+1, foxaudio...@gmail.com  wrote:
> While learning about the TI-99 a little more I took a read through some docs on
> the MSP430 and found a familiar looking assembly language.
> 
> In a doc "TI called MSP430 competitive benchmarks" I found some C language
> examples and as I looked at one I thought about how would one do this is
> Forth.  I have always been fascinated (envious too) by the way some Forth
> coders can really exploit the alternate paradigm that Forth provides.
> 
> 
> Here is the C program:
> \ ******************************************************************************
> \ *
> \ * Name : 8-bit 2-dim Matrix 
> \ * Purpose : Benchmark copying 8-bit values.
> \ *
> \ *****************************************************************************/
> \ typedef unsigned char UInt8;
> \ const UInt8 m1[16][4] = {
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12},
> \                            {0x12, 0x56, 0x90, 0x34},
> \                            {0x78, 0x12, 0x56, 0x90},
> \                            {0x34, 0x78, 0x12, 0x56},
> \                            {0x90, 0x34, 0x78, 0x12}
> \                                                     };
> \ void  main(void)
> \ {
> \      int i,j;
> \      volatile UInt8 m2[16][4], m3[16][4];
> \      for(i=0;i<16;i++)
> \      {
> \         for(j=0;j<4;j++)
> \         {
> \            m2[i][j]=m1[i][j];
> \            m3[i][j]=m2[i][j];
> \         }
> \      }
> \      return;
> \ }
> 
> And here is my "vanilla" version attempting to emulate the the C coding style
> creating a very simple and at the same time sub-optimal program in Forth.
> 
> \ Forth Equivalent written something like C
> \ Yes, I know it uses static allocations which is typical Forth
> 
> create m1   HEX  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
>                  12 c, 56 c, 90 c, 34  c,
>                  78 c, 12 c, 56 c, 90  c,
>                  34 c, 78 c, 12 c, 56  c,
>                  90 c, 34 c, 78 c, 12  c,
> 
> DECIMAL
>   4 16 * constant 4x16
> 
>   4x16 buffer: m2
>   4x16 buffer: m3
> 
> \ ==================================================================
> \ forth needs byte matrix operators but they are simple
> 
> : []     ( x y addr -- addr' ) + swap 4 * + ;
> : []c@   ( x y addr -- char )  [] c@ ;
> : []c!   ( char x y addr -- )  [] c! ;
> 
> : main()
>             16 0 do
>                4 0 do
>                    j i m1 []c@  j i m2 []c!
>                    j i m2 []c@  j i m3 []c!
>                loop
>             loop ;
> 
> 
> However of course in Forth one would just do:
> 
> : fmain
>             m1 m2 4x16 cmove
>             m2 m3 4x16 cmove ;
> 
> The speed improvement on my 16bit ITC system is 7.8X vs the C style version.
> 
> 
> Does anyone have examples of code where they can contrast the conventional method versus Forth?
> 
> BF

What led you to be looking at the TI-99?

Have you seen TurboForth?

[toc] | [prev] | [next] | [standalone]

#49013

Fromfoxaudioresearch@gmail.com
Date2016-07-10 08:50 -0700
Message-ID<8fc90f76-ca06-498d-b12a-603ea8647079@googlegroups.com>
In reply to#49005
Sure have Mark. It's very nice.  

I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.

The cycle count looks like it will be faster.


Boy I like that TmS9900 instruction set better than x86.

Just needs a stack pointer or 2 in Hardware.

B

[toc] | [prev] | [next] | [standalone]

#49023

FromMark Wills <markwills1970@gmail.com>
Date2016-07-10 15:00 -0700
Message-ID<2159c4c3-114b-42a0-b04c-3efb928679fc@googlegroups.com>
In reply to#49013
On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
> Sure have Mark. It's very nice.  
> 
> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
> 
> The cycle count looks like it will be faster.
> 
> 
> Boy I like that TmS9900 instruction set better than x86.
> 
> Just needs a stack pointer or 2 in Hardware.
> 
> B

Yes, the TMS9900 instruction set is by the nicest I've used on any processor
over the years. The 68K comes a close second for me :-)

[toc] | [prev] | [next] | [standalone]

#49027

Fromrickman <gnuarm@gmail.com>
Date2016-07-10 22:53 -0400
Message-ID<nlv1o0$8au$1@dont-email.me>
In reply to#49023
On 7/10/2016 6:00 PM, Mark Wills wrote:
> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
>> Sure have Mark. It's very nice.
>>
>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
>>
>> The cycle count looks like it will be faster.
>>
>>
>> Boy I like that TmS9900 instruction set better than x86.
>>
>> Just needs a stack pointer or 2 in Hardware.
>>
>> B
>
> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
> over the years. The 68K comes a close second for me :-)

Funny, I still have a couple of TMS99x computers around here somewhere. 
One is a Technico 9900 single board computer that uses EPROMs.  Another 
is one I designed using a 9995 built with wire wrap.  I wanted to use 
the 9995 to control an IBM Selectric I got at a something-fest, but it 
was too worn out to print reliably.  Seems those mechanicals don't last 
forever.  Both CPU boards are sitting in my basement next to an old 8008 
multiple board computer.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49034

FromMark Wills <markwills1970@gmail.com>
Date2016-07-11 01:59 -0700
Message-ID<ea119550-f0a9-4e35-9e2b-4e2a36968101@googlegroups.com>
In reply to#49027
On Monday, 11 July 2016 03:53:53 UTC+1, rickman  wrote:
> On 7/10/2016 6:00 PM, Mark Wills wrote:
> > On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
> >> Sure have Mark. It's very nice.
> >>
> >> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
> >>
> >> The cycle count looks like it will be faster.
> >>
> >>
> >> Boy I like that TmS9900 instruction set better than x86.
> >>
> >> Just needs a stack pointer or 2 in Hardware.
> >>
> >> B
> >
> > Yes, the TMS9900 instruction set is by the nicest I've used on any processor
> > over the years. The 68K comes a close second for me :-)
> 
> Funny, I still have a couple of TMS99x computers around here somewhere. 
> One is a Technico 9900 single board computer that uses EPROMs.  Another 
> is one I designed using a 9995 built with wire wrap.  I wanted to use 
> the 9995 to control an IBM Selectric I got at a something-fest, but it 
> was too worn out to print reliably.  Seems those mechanicals don't last 
> forever.  Both CPU boards are sitting in my basement next to an old 8008 
> multiple board computer.
> 
> -- 
> 
> Rick C

The 9995s and (in-particular) the 9900s are getting quite valuable now. The
9995 is a much simpler chip to work with. IIRC it needs no supporting chippery,
whereas the 9900 at least requires a 4-phase clock. Their register to memory
architecture is beautiful. If only they had a hardware stack! (Later variants
of the 99xx family did indeed have hardware stacks and a whole raft of
additional instructions).

[toc] | [prev] | [next] | [standalone]

#49040

Fromrickman <gnuarm@gmail.com>
Date2016-07-11 09:44 -0400
Message-ID<nm07sh$n94$2@dont-email.me>
In reply to#49034
On 7/11/2016 4:59 AM, Mark Wills wrote:
> On Monday, 11 July 2016 03:53:53 UTC+1, rickman  wrote:
>> On 7/10/2016 6:00 PM, Mark Wills wrote:
>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
>>>> Sure have Mark. It's very nice.
>>>>
>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
>>>>
>>>> The cycle count looks like it will be faster.
>>>>
>>>>
>>>> Boy I like that TmS9900 instruction set better than x86.
>>>>
>>>> Just needs a stack pointer or 2 in Hardware.
>>>>
>>>> B
>>>
>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
>>> over the years. The 68K comes a close second for me :-)
>>
>> Funny, I still have a couple of TMS99x computers around here somewhere.
>> One is a Technico 9900 single board computer that uses EPROMs.  Another
>> is one I designed using a 9995 built with wire wrap.  I wanted to use
>> the 9995 to control an IBM Selectric I got at a something-fest, but it
>> was too worn out to print reliably.  Seems those mechanicals don't last
>> forever.  Both CPU boards are sitting in my basement next to an old 8008
>> multiple board computer.
>>
>> --
>>
>> Rick C
>
> The 9995s and (in-particular) the 9900s are getting quite valuable now. The
> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery,
> whereas the 9900 at least requires a 4-phase clock. Their register to memory
> architecture is beautiful. If only they had a hardware stack! (Later variants
> of the 99xx family did indeed have hardware stacks and a whole raft of
> additional instructions).

Why would you want a hardware stack?  That would be limited in size and 
likely function.  The 8008 predecessor to the 8080 has a small hardware 
stack.

Or do you mean a dedicated stack pointer in the chip?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49052

FromMark Wills <markwills1970@gmail.com>
Date2016-07-11 10:51 -0700
Message-ID<9a73adb8-c83b-4ef1-b504-9507239577f3@googlegroups.com>
In reply to#49040
On Monday, 11 July 2016 14:44:51 UTC+1, rickman  wrote:
> On 7/11/2016 4:59 AM, Mark Wills wrote:
> > On Monday, 11 July 2016 03:53:53 UTC+1, rickman  wrote:
> >> On 7/10/2016 6:00 PM, Mark Wills wrote:
> >>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
> >>>> Sure have Mark. It's very nice.
> >>>>
> >>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
> >>>>
> >>>> The cycle count looks like it will be faster.
> >>>>
> >>>>
> >>>> Boy I like that TmS9900 instruction set better than x86.
> >>>>
> >>>> Just needs a stack pointer or 2 in Hardware.
> >>>>
> >>>> B
> >>>
> >>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
> >>> over the years. The 68K comes a close second for me :-)
> >>
> >> Funny, I still have a couple of TMS99x computers around here somewhere.
> >> One is a Technico 9900 single board computer that uses EPROMs.  Another
> >> is one I designed using a 9995 built with wire wrap.  I wanted to use
> >> the 9995 to control an IBM Selectric I got at a something-fest, but it
> >> was too worn out to print reliably.  Seems those mechanicals don't last
> >> forever.  Both CPU boards are sitting in my basement next to an old 8008
> >> multiple board computer.
> >>
> >> --
> >>
> >> Rick C
> >
> > The 9995s and (in-particular) the 9900s are getting quite valuable now. The
> > 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery,
> > whereas the 9900 at least requires a 4-phase clock. Their register to memory
> > architecture is beautiful. If only they had a hardware stack! (Later variants
> > of the 99xx family did indeed have hardware stacks and a whole raft of
> > additional instructions).
> 
> Why would you want a hardware stack?  That would be limited in size and 
> likely function.  The 8008 predecessor to the 8080 has a small hardware 
> stack.
> 
> Or do you mean a dedicated stack pointer in the chip?
> 
> -- 
> 
> Rick C

Yes, just a stack pointer, and MOV instructions to get push/pop.

It's fairly simple to anyway. Suppose R0 is your stack pointer register:

LI R0,$E000 - stack is at $E000

to push data:
DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes)
MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0

to pop:
MOV *R0+,Rx  - move data at address addressed by R0 to Rx, and increase R0 by two

[toc] | [prev] | [next] | [standalone]

#49059

Fromrickman <gnuarm@gmail.com>
Date2016-07-11 15:26 -0400
Message-ID<nm0rss$95j$1@dont-email.me>
In reply to#49052
On 7/11/2016 1:51 PM, Mark Wills wrote:
> On Monday, 11 July 2016 14:44:51 UTC+1, rickman  wrote:
>> On 7/11/2016 4:59 AM, Mark Wills wrote:
>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman  wrote:
>>>> On 7/10/2016 6:00 PM, Mark Wills wrote:
>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
>>>>>> Sure have Mark. It's very nice.
>>>>>>
>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
>>>>>>
>>>>>> The cycle count looks like it will be faster.
>>>>>>
>>>>>>
>>>>>> Boy I like that TmS9900 instruction set better than x86.
>>>>>>
>>>>>> Just needs a stack pointer or 2 in Hardware.
>>>>>>
>>>>>> B
>>>>>
>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
>>>>> over the years. The 68K comes a close second for me :-)
>>>>
>>>> Funny, I still have a couple of TMS99x computers around here somewhere.
>>>> One is a Technico 9900 single board computer that uses EPROMs.  Another
>>>> is one I designed using a 9995 built with wire wrap.  I wanted to use
>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it
>>>> was too worn out to print reliably.  Seems those mechanicals don't last
>>>> forever.  Both CPU boards are sitting in my basement next to an old 8008
>>>> multiple board computer.
>>>>
>>>> --
>>>>
>>>> Rick C
>>>
>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The
>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery,
>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory
>>> architecture is beautiful. If only they had a hardware stack! (Later variants
>>> of the 99xx family did indeed have hardware stacks and a whole raft of
>>> additional instructions).
>>
>> Why would you want a hardware stack?  That would be limited in size and
>> likely function.  The 8008 predecessor to the 8080 has a small hardware
>> stack.
>>
>> Or do you mean a dedicated stack pointer in the chip?
>>
>> --
>>
>> Rick C
>
> Yes, just a stack pointer, and MOV instructions to get push/pop.
>
> It's fairly simple to anyway. Suppose R0 is your stack pointer register:
>
> LI R0,$E000 - stack is at $E000
>
> to push data:
> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes)
> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0
>
> to pop:
> MOV *R0+,Rx  - move data at address addressed by R0 to Rx, and increase R0 by two

But in the TMS9900 R0 is in memory.  You are talking about a hardware 
stack pointer which would require new instructions like:

PUSH R0 - to push the contents of R0 on the stack

Or if you want to share the common syntax,

DECT SP
MOV Rx,*SP
MOV *SP+,Rx

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49087

FromMark Wills <markwills1970@gmail.com>
Date2016-07-12 15:18 -0700
Message-ID<b10900d8-3231-4ff2-931b-1d69403a92e0@googlegroups.com>
In reply to#49059
Yes, that sort of thing would have been nice. It's a lovely orthogonal instruction set. There are very few special cases.

[toc] | [prev] | [next] | [standalone]

#49512

Fromfoxaudioresearch@gmail.com
Date2016-07-25 19:56 -0700
Message-ID<26ea96b4-07db-4dbe-89f9-935c3e8bae28@googlegroups.com>
In reply to#49052
On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote:
> On Monday, 11 July 2016 14:44:51 UTC+1, rickman  wrote:
> > On 7/11/2016 4:59 AM, Mark Wills wrote:
> > > On Monday, 11 July 2016 03:53:53 UTC+1, rickman  wrote:
> > >> On 7/10/2016 6:00 PM, Mark Wills wrote:
> > >>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
> > >>>> Sure have Mark. It's very nice.
> > >>>>
> > >>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
> > >>>>
> > >>>> The cycle count looks like it will be faster.
> > >>>>
> > >>>>
> > >>>> Boy I like that TmS9900 instruction set better than x86.
> > >>>>
> > >>>> Just needs a stack pointer or 2 in Hardware.
> > >>>>
> > >>>> B
> > >>>
> > >>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
> > >>> over the years. The 68K comes a close second for me :-)
> > >>
> > >> Funny, I still have a couple of TMS99x computers around here somewhere.
> > >> One is a Technico 9900 single board computer that uses EPROMs.  Another
> > >> is one I designed using a 9995 built with wire wrap.  I wanted to use
> > >> the 9995 to control an IBM Selectric I got at a something-fest, but it
> > >> was too worn out to print reliably.  Seems those mechanicals don't last
> > >> forever.  Both CPU boards are sitting in my basement next to an old 8008
> > >> multiple board computer.
> > >>
> > >> --
> > >>
> > >> Rick C
> > >
> > > The 9995s and (in-particular) the 9900s are getting quite valuable now. The
> > > 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery,
> > > whereas the 9900 at least requires a 4-phase clock. Their register to memory
> > > architecture is beautiful. If only they had a hardware stack! (Later variants
> > > of the 99xx family did indeed have hardware stacks and a whole raft of
> > > additional instructions).
> > 
> > Why would you want a hardware stack?  That would be limited in size and 
> > likely function.  The 8008 predecessor to the 8080 has a small hardware 
> > stack.
> > 
> > Or do you mean a dedicated stack pointer in the chip?
> > 
> > -- 
> > 
> > Rick C
> 
> Yes, just a stack pointer, and MOV instructions to get push/pop.
> 
> It's fairly simple to anyway. Suppose R0 is your stack pointer register:
> 
> LI R0,$E000 - stack is at $E000
> 
> to push data:
> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes)
> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0
> 
> to pop:
> MOV *R0+,Rx  - move data at address addressed by R0 to Rx, and increase R0 by two

I always feel cramped with the single level sub-routine call linked in R11. 
(Branch and link)
Although it sucks up way too many cycles on these machines, I created a macros
in Forth assembler that let me have what I want when I need it.

\ PUSH & POP on both stacks
: PUSH,         ( src -- )  SP DECT,  *SP   MOV, ;   
: POP,          ( dst -- )  *SP+      SWAP  MOV, ;   

: RPUSH,        ( src -- ) RP DECT,  *RP   MOV,  ;
: RPOP,         ( dst -- ) *RP+      SWAP  MOV,  ;

Then I extended branch & link.

: CALL,         ( dst -- ) R11 RPUSH,  ( addr) BL,   R11 RPOP, ;

And return remains the same:
: RT   *R11 B, ;    

If only it was in hardware...

BF

[toc] | [prev] | [next] | [standalone]

#49514

Fromrickman <gnuarm@gmail.com>
Date2016-07-25 23:13 -0400
Message-ID<nn6kh3$sa4$1@dont-email.me>
In reply to#49512
On 7/25/2016 10:56 PM, foxaudioresearch@gmail.com wrote:
> On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote:
>> On Monday, 11 July 2016 14:44:51 UTC+1, rickman  wrote:
>>> On 7/11/2016 4:59 AM, Mark Wills wrote:
>>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman  wrote:
>>>>> On 7/10/2016 6:00 PM, Mark Wills wrote:
>>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
>>>>>>> Sure have Mark. It's very nice.
>>>>>>>
>>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
>>>>>>>
>>>>>>> The cycle count looks like it will be faster.
>>>>>>>
>>>>>>>
>>>>>>> Boy I like that TmS9900 instruction set better than x86.
>>>>>>>
>>>>>>> Just needs a stack pointer or 2 in Hardware.
>>>>>>>
>>>>>>> B
>>>>>>
>>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
>>>>>> over the years. The 68K comes a close second for me :-)
>>>>>
>>>>> Funny, I still have a couple of TMS99x computers around here somewhere.
>>>>> One is a Technico 9900 single board computer that uses EPROMs.  Another
>>>>> is one I designed using a 9995 built with wire wrap.  I wanted to use
>>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it
>>>>> was too worn out to print reliably.  Seems those mechanicals don't last
>>>>> forever.  Both CPU boards are sitting in my basement next to an old 8008
>>>>> multiple board computer.
>>>>>
>>>>> --
>>>>>
>>>>> Rick C
>>>>
>>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The
>>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery,
>>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory
>>>> architecture is beautiful. If only they had a hardware stack! (Later variants
>>>> of the 99xx family did indeed have hardware stacks and a whole raft of
>>>> additional instructions).
>>>
>>> Why would you want a hardware stack?  That would be limited in size and
>>> likely function.  The 8008 predecessor to the 8080 has a small hardware
>>> stack.
>>>
>>> Or do you mean a dedicated stack pointer in the chip?
>>>
>>> --
>>>
>>> Rick C
>>
>> Yes, just a stack pointer, and MOV instructions to get push/pop.
>>
>> It's fairly simple to anyway. Suppose R0 is your stack pointer register:
>>
>> LI R0,$E000 - stack is at $E000
>>
>> to push data:
>> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes)
>> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0
>>
>> to pop:
>> MOV *R0+,Rx  - move data at address addressed by R0 to Rx, and increase R0 by two
>
> I always feel cramped with the single level sub-routine call linked in R11.
> (Branch and link)
> Although it sucks up way too many cycles on these machines, I created a macros
> in Forth assembler that let me have what I want when I need it.
>
> \ PUSH & POP on both stacks
> : PUSH,         ( src -- )  SP DECT,  *SP   MOV, ;
> : POP,          ( dst -- )  *SP+      SWAP  MOV, ;
>
> : RPUSH,        ( src -- ) RP DECT,  *RP   MOV,  ;
> : RPOP,         ( dst -- ) *RP+      SWAP  MOV,  ;
>
> Then I extended branch & link.
>
> : CALL,         ( dst -- ) R11 RPUSH,  ( addr) BL,   R11 RPOP, ;
>
> And return remains the same:
> : RT   *R11 B, ;
>
> If only it was in hardware...

These days a TMS9900 processor could be done in an FPGA and run much 
faster than the original.  It could also look ahead at the instruction 
sequences you use and do them in a single instruction (even though it 
would still need to fetch it all to do the lookahead).  This could 
maintain machine code level compatibility and work much faster.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#49529

Fromjim.brakefield@ieee.org
Date2016-07-26 07:34 -0700
Message-ID<117b3726-b027-4e64-ac08-2aedb0d0f880@googlegroups.com>
In reply to#49514
On Monday, July 25, 2016 at 10:13:41 PM UTC-5, rickman wrote:
> On 7/25/2016 10:56 PM, foxaudioresearch@gmail.com wrote:
> > On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote:
> >> On Monday, 11 July 2016 14:44:51 UTC+1, rickman  wrote:
> >>> On 7/11/2016 4:59 AM, Mark Wills wrote:
> >>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman  wrote:
> >>>>> On 7/10/2016 6:00 PM, Mark Wills wrote:
> >>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com  wrote:
> >>>>>>> Sure have Mark. It's very nice.
> >>>>>>>
> >>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register.
> >>>>>>>
> >>>>>>> The cycle count looks like it will be faster.
> >>>>>>>
> >>>>>>>
> >>>>>>> Boy I like that TmS9900 instruction set better than x86.
> >>>>>>>
> >>>>>>> Just needs a stack pointer or 2 in Hardware.
> >>>>>>>
> >>>>>>> B
> >>>>>>
> >>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor
> >>>>>> over the years. The 68K comes a close second for me :-)
> >>>>>
> >>>>> Funny, I still have a couple of TMS99x computers around here somewhere.
> >>>>> One is a Technico 9900 single board computer that uses EPROMs.  Another
> >>>>> is one I designed using a 9995 built with wire wrap.  I wanted to use
> >>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it
> >>>>> was too worn out to print reliably.  Seems those mechanicals don't last
> >>>>> forever.  Both CPU boards are sitting in my basement next to an old 8008
> >>>>> multiple board computer.
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Rick C
> >>>>
> >>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The
> >>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery,
> >>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory
> >>>> architecture is beautiful. If only they had a hardware stack! (Later variants
> >>>> of the 99xx family did indeed have hardware stacks and a whole raft of
> >>>> additional instructions).
> >>>
> >>> Why would you want a hardware stack?  That would be limited in size and
> >>> likely function.  The 8008 predecessor to the 8080 has a small hardware
> >>> stack.
> >>>
> >>> Or do you mean a dedicated stack pointer in the chip?
> >>>
> >>> --
> >>>
> >>> Rick C
> >>
> >> Yes, just a stack pointer, and MOV instructions to get push/pop.
> >>
> >> It's fairly simple to anyway. Suppose R0 is your stack pointer register:
> >>
> >> LI R0,$E000 - stack is at $E000
> >>
> >> to push data:
> >> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes)
> >> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0
> >>
> >> to pop:
> >> MOV *R0+,Rx  - move data at address addressed by R0 to Rx, and increase R0 by two
> >
> > I always feel cramped with the single level sub-routine call linked in R11.
> > (Branch and link)
> > Although it sucks up way too many cycles on these machines, I created a macros
> > in Forth assembler that let me have what I want when I need it.
> >
> > \ PUSH & POP on both stacks
> > : PUSH,         ( src -- )  SP DECT,  *SP   MOV, ;
> > : POP,          ( dst -- )  *SP+      SWAP  MOV, ;
> >
> > : RPUSH,        ( src -- ) RP DECT,  *RP   MOV,  ;
> > : RPOP,         ( dst -- ) *RP+      SWAP  MOV,  ;
> >
> > Then I extended branch & link.
> >
> > : CALL,         ( dst -- ) R11 RPUSH,  ( addr) BL,   R11 RPOP, ;
> >
> > And return remains the same:
> > : RT   *R11 B, ;
> >
> > If only it was in hardware...
> 
> These days a TMS9900 processor could be done in an FPGA and run much 
> faster than the original.  It could also look ahead at the instruction 
> sequences you use and do them in a single instruction (even though it 
> would still need to fetch it all to do the lookahead).  This could 
> maintain machine code level compatibility and work much faster.
> 
> -- 
> 
> Rick C

]>These days a TMS9900 processor could be done in an FPGA and run much 
> faster than the original.

Check out neo430 and openmsp430 at opencores.org (in processor section).
neo430 can achieve a clock rate of 264MHz and openmsp430 116 MHz
(different implementations, so speed not directly proportional to fmax)

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.forth

csiph-web