Prime Number Prog as Benchmark for my Gigatron build

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
Post Reply
Posts: 6
Joined: 28 Nov 2018, 20:21

Prime Number Prog as Benchmark for my Gigatron build

Post by wtlprnft » 22 Dec 2018, 21:27

Hi Community,
As my first soldering project I built the gigatron without any error, thanks for the great instructions!!
As benchmark I did a quick and dirty Program, that computes all prime numbers from 2-32767. Ofcourse, all the usual arithmetical improvemnets are implemented, as they are: only dividing thru earlier computed prime numbers till the half of the tested number and ofcourse only testing odd numbers above 2. I am not a programmer, so I am sure there are many of improvement possibilities in code, so any improvement suggestions are greatly welcome!! The last displayed number on screen is the 3512, the number of found prime numbers. The referenced basic program on github takes about 3 minutes for 1-200, my version about 2 seconds, the whole run till 32767 is about 3 hours and 45 minutes in lowest vga mode. if you are interested, my code is attached, the display of the computed prime numbers is copied from the examples directory.

many thanks to the originators of that great project, I do it for educational purpose and its great therefor!

(5.25 KiB) Downloaded 39 times

User avatar
Posts: 252
Joined: 13 May 2018, 08:26

Re: Prime Number Prog as Benchmark for my Gigatron build

Post by marcelk » 27 Dec 2018, 11:22

3512 must be correct! The code looks as fine as GCL can be. GCL can't be pretty, it's all about the comments. The BM9.gtb BASIC program is part of a famous benchmark from the early 1980s. It has inefficiencies that are deliberate. If you have a GitHub account, please publish the program in Contrib/.

I take this opportunity to explain the compiler's output.

Invoking the offline GCL compiler can be done from the root directory of the repo, or by using "make".

Code: Select all

bash> make prime.gt1 
Core/ "prime.gcl" `dirname ./"prime.gt1"`
Compiling file prime.gcl
While working on a larger program, you often find yourself moving functions around, redistributing them over the pages (segments). That's why the page usage is always shown. The compiler is aware of the standard memory map. From some reason we use hexadecimal notation for memory addresses, but decimal otherwise.

Code: Select all

 Segment at 0200 size 250 used  49 unused 201
 Segment at 0300 size 250 used 200 unused  50
 Segment at 0400 size 250 used 193 unused  57
 Segment at 0500 size 256 used 222 unused  34
The number of global variables is shown next. They live in the zero page and are allocated in order of appearance.

Code: Select all

 Variables count 33 bytes 66 end 0072
Next comes the symbol table in alphabetic order. I use that mostly to detect mistyped names. Variables don't need to be declared upfront BTW. The introduction of each new name allocates two bytes from the zero page.

Code: Select all

 : AnzahlPrimzahlen Char ClearScreenV1 [53] ClearScreenV3 [35] Color D
 : DRead DrawChar [113] DrawNextDigit [45] DrawNumber [39] I Isprime N
 : NewLine [16] Pos R Radix ReadPrime [32] Teiler Teilerhalbe Value
 : WritePrime [32] X ZZ bits fontData halt [22] i p q tmp x y
For "defines" (def), the size is listed in square brackets. The number isn't always quite right, but normally it is good enough to decide how things can move to other segments, when so desired.

For programs that use "vLR hopping", the Loader patch is applied automatically.

Code: Select all

Apply patch 5b86
Execute at 5b86
Finally, the GT1 file is written.

Code: Select all

Create file ./prime.gt1
OK size 688
GT1 file attached below.
(998.67 KiB) Downloaded 21 times
(688 Bytes) Downloaded 30 times

Post Reply