BASIC code to test compilers

[PeterJ]

I know compilers were tested by all the magazines in the 80s, and various pieces of sample code were used.

I'm looking to spend some time testing and documenting the results for as many compilers as I could find, and wondered if anyone could suggest some code which would be a good multi-part test. Just a reminder that many compilers only work on integer numbers, and some only allow 26 variables. The same code has to run on all compilers I test.

Thanks

Peter

[equinox]

I assume you want to test them in a sort of "computational" way (actually non-Speccy), and not things like "how fast can we draw a line" -- which might be outsourced to the ROM anyway?

Then it would make sense to pick the "textbook" algorithms, like sorting, and graph theory. For example, why not do quicksort over 1000 numbers, or solve Travelling Salesman algorithm?

You mentioned that some compilers expect integers, but remember some of them make it an option. I used HiSoft BASIC a lot, and you can either just compile your BASIC (where any numeric variable might have fractional part) or you can write special REM statements saying that certain variables are guaranteed to be integers. As you can imagine, this may make things a lot faster.

[PeterJ]

ZIP (One I'm testing now) is integer only.

[Waldroid]

Code: Select all

10 PRINT "Speccys are ace!"
20 GO TO 10

[Turtle_Quality]

I know Waldroid was joking, but clearly if you want to compare timing of certain instructions it's probably better to loop through it a fixed, larger number of times, say 10,000

MCoder and MCoder II were integer only, and had a few other restrictions quite well documented in their instructions - arrays only one dimensional, RND returns an integer up to 32767 not something between 0 and 1, GOTO and GOSUB have to point to fixed line numbers, Boolean maths not allowed (LET X=X+INKEY$="p")

It also has different TRACE levels that drastically effect the speed.

I know you were looking at ZIP first, but you might find similar issues there

As hinted by equinox, the likes of BEEP, DRAW, CIRCLE, and possibly PRINT would quite likely just call the standard ROM routines, the main saving in compilers is made by not interpreting and error checking each statement as you perform it. Handling integers instead of floating point is also a significant time saver

[equinox]

As hinted by equinox, the likes of BEEP, DRAW, CIRCLE, and possibly PRINT would quite likely just call the standard ROM routines, the main saving in compilers is made by not interpreting and error checking each statement as you perform it. Handling integers instead of floating point is also a significant time saver

Thanks. I actually thought "ok I'll write quicksort, how hard can it be?" and then after writing DIM a(500) and remembering that we don't have either local scope, or bounds checks*, I cried and gave up. (Recursion is enough fun when you have scope.) Haha! The problem of implementing textbook stuff in Spectrum BASIC is absolutely not a problem of memory or CPU, it's just how am I going to use this awful BASIC to code it. We've been spoiled with data structures and templates. [Well, I guess half the people reading this can write assembler, but do you know what you've got, that BASIC hasn't got? PUSH and POP†]

All right, I've got a really easy one: why not do Fisher–Yates shuffle on a deck of 1000 cards. That's a one-liner.

* something something C
† actually I think Sam Coupé BASIC has these things -- born too young, died too soon

[PeterJ]

Some interesting ones here;

https://en.m.wikipedia.org/wiki/Rugg/Feldman_benchmarks

[Wall_Axe]

How about a demo of drawing a line from the centre of the screen to 20 pixels out....at 360 angles.
This would test the sin&cos and line drawing capabilities.

I suppose then you could just test :
multiplacation
Square root
Iteration through arrays
Altering and reading slicing strings

In seperate demos
I suppose putting those things into one demo might be a better test.
Those are things that get used in games a lot

You could come up with some graphic tests if you knew the similarities in graphics commands the basics have

[TomD]

Simple test is just to do a print loop. Following code shows the time to print 1000 numbers. It takes 18560mS in BASIC and with MCODER II it takes 3000mS

Code: Select all

10 CLS
20 LET a=65536*PEEK 23674+256*PEEK 23673+PEEK 23672
30 FOR i=0 TO 1000: PRINT AT 0,0;i: NEXT i
40 LET b=65536*PEEK 23674+256*PEEK 23673+PEEK 23672
50 PRINT (b-a)*20,"mS"

TomD

[TomD]

You can also check some of the graphic routines. Interestingly MCODER II is no faster than basic at plotting CIRCLES, both taking around 12seconds to plot 20.

Code: Select all

10 CLS
20 LET a=65536*PEEK 23674+256*PEEK 23673+PEEK 23672
30 FOR i=0 TO 20: PRINT AT 0,0;i: CIRCLE 128,96,20: NEXT i
40 LET b=65536*PEEK 23674+256*PEEK 23673+PEEK 23672
50 PRINT (b-a)*20,"mS"

[TomD]

And to cap off the test here is a simple PLOT test. MCODER is faster this time @560mS vs. 3820mS for BASIC

Code: Select all

10 CLS
20 LET a=65536*PEEK 23674+256*PEEK 23673+PEEK 23672
30 FOR i=0 TO 175: PRINT AT 0,0;i: PLOT i,i: NEXT i
40 LET b=65536*PEEK 23674+256*PEEK 23673+PEEK 23672
50 PRINT (b-a)*20,"mS"

[PeterJ]

Thanks so much @TomD for the three examples. Unfortunately, ZIP 2 Compilers seems to complain. I suppose I'm learning about the shortcomings.



Linked to this, can I wholeheartedly recommend InkSpector from @Inky. It has a wonderful feature which lets you spool BASIC on the clipboard directly into the Spectrum. Saves so much time! I love it!

[TomD]

Thanks so much @TomD for the three examples. Unfortunately, ZIP 2 Compilers seems to complain. I suppose I'm learning about the shortcomings.



Can I heartedly recommend InkSpector from @Inky. It has a wonderful feature which lets you spool BASIC on the clipboard directly into the Spectrum. Saves so much time! I love it!

Interesting, I only tested MCODER II and SOFTEK IS which are both fine. The code it is complaining about is just the timing. If you remove the

Code: Select all

65536*PEEK 23674

part it should be fine. This isn't really needed as it never runs for that long. Although it could be an issue if it overflows so might be better to reset them first which a POKE

TomD

[Pobulous]

How about a Prime Sieve. I've kept it simple so no AND or OR in IF statements.

1 R£M Prime Sieve
10 DIM p$(1000)
20 FOR n=2 to 1000
30 LET p$(n)="T"
40 NEXT n

50 LET t=2

100 IF t>499 THEN GOTO 200
110 IF p$(t)="F" THEN GOTO 150
120 FOR n=t+t to 1000 step t
130 LET p$(n)="F"
140 NEXT n
150 LET t=t+1
160 GOTO 100

200 FOR n=2 to 79
210 IF P$(n)="T" THEN PRINT n
220 NEXT n

[PeterJ]

Thanks @TomD. Nice use of the frame counter system variables!

Test one with ZIP took 2900mS (So, fastest)

Test two failed as the CIRCLE command is not supported

Test three with ZIP to 520mS (again, fastest)

The ZIP compiler is still available from Simon Goodwin for the princely sum of £5 (including printed a printed manual from the 80s!)

Going back to something @Turtle_Quality was saying in reply to my question about compiled BASIC and smooth scrolling being possible by mixing a sprite assembly routine with the compiled BASIC, I assume if I put my sprite code under 53247 I should be able to call it from ZIP (or whichever compiler I use - Obviously changing the address to suit)? Edit - Just read the post by @Joefish on another option from BASIC using udg banks which is a great idea.

[PeterJ]

Thanks @Pobulous,

Unfortunately ZIP does not allow string arrays.

[Pobulous]

With numeric array, although it's a bit unfair to BASIC as it will be using FP numbers

1 R£M Prime Sieve
10 DIM p(1000)
20 FOR n=2 to 1000
30 LET p(n)=1
40 NEXT n

50 LET t=2

100 IF t>499 THEN GOTO 200
110 IF p(t)=0 THEN GOTO 150
120 FOR n=t+t to 1000 step t
130 LET p(n)=0
140 NEXT n
150 LET t=t+1
160 GOTO 100

200 FOR n=2 to 79
210 IF P(n)=1 THEN PRINT n
220 NEXT n

[PeterJ]

Thanks @Pobulous,

28,300 mS in BASIC

260mS with ZIP

I appreciate you comment about it being a little unfair on BASIC. Timing borrowed from @TomD!

Code: Select all

 5 POKE 23692,255
10 DIM p(1000)
20 FOR n=2 TO 1000
30 LET p(n)=1
40 NEXT n
45 LET t=2
50 LET a=256*PEEK 23673+PEEK 23672
100 IF t>499 THEN GO TO  200
110 IF p(t)=0 THEN GO TO  150
120 FOR n=t+t TO 1000 STEP t
130 LET p(n)=0
140 NEXT n
150 LET t=t+1
160 GO TO  100
200 FOR n=2 TO 79
210 IF P(n)=1 THEN PRINT n
220 NEXT n
250 LET b=256*PEEK 23673+PEEK 23672
300 PRINT (b-a)*20,"ms"

EDITED.

[TomD]

Another one, this time a simple bubble sort, 200mS with MCODER II, 5560mS in BASIC

Code: Select all

10 CLS
20 POKE 23673,0: POKE 23672,0
30 LET a=256*PEEK 23673+PEEK 23672
40 DIM n(20): FOR i=1 TO 20: READ n(i): NEXT i
50 FOR i=1 TO 20: PRINT AT i-1,0;i;":";n(i): NEXT i
60 LET i=1
70 FOR j=i+1 TO 20
80 IF n(i)>n(j) THEN LET m=n(i): LET n(i)=n(j): LET n(j)=m
90 NEXT j
100 LET i=i+1
110 IF i<20 THEN GO TO 70
120 FOR i=1 TO 20: PRINT AT i-1,10;i;":";n(i): NEXT i
130 LET b=256*PEEK 23673+PEEK 23672
140 PRINT AT 21,0;"Run in "; (b-a)*20,"mS"
150 DATA 76,33,7,124,25,134,21,88,44,54,12,467,34,78,2113,74,323,7699,223,1

[Waldroid]

My OCD is compelling me to write that "mS" is milli-siemens, the unit of conductance.

"ms" is milli-seconds.

[PeterJ]

Thanks @TomD. Sadly, no read or data in ZIP. I'm finding it's very fast, but not very comprehensive in it's support of BASIC keywords. It's described as being able to compile a large 'subset' of ZX BASIC. Not sure I agree with that. Excellent, if you don't need the extra commands though.

[TomD]

Thanks @TomD. Sadly, no read or data in ZIP. I'm finding it's very fast, but not very comprehensive in it's support of BASIC keywords. It's described as being able to compile a large 'subset' of ZX BASIC. Not sure I agree with that. Excellent, if you don't need the extra commands though.

Yeah my go to was always MCODER II back in the day, still have my original copy It does seem to handle a lot more.

TomD

[Pobulous]

MCoder II was what I used, too.

Interestingly my prime sieve wouldn't compile with it cos it doesn't support STEP, ha ha.

Whilst it says it supports AND and OR in IF statements, the version I had was definitely bugged when using them leading to much hair pulling debugging code which then worked if replaced with IF ... THEN IF .... THEN IF .... for AND
OR would be IF NOT .... THEN IF NOT ... THEN IF NOT .... THEN GOTO nomatch.

[PeterJ]

Thanks for all the help with this. I never read Tech Niche in Crash as a child, but now it's my favourite bit. We should bring it back!

[Turtle_Quality]

The only drawback with using Frames as a timer is that you're assuming the interrupts are always enabled. The ROMs BEEP will disable interrupts temporarily, we can't be sure what compilers might do with interrupts, especially compilers with different trace levels like MCoder. Quite likely nothing, I'm probably just displaying nerdy levels of caution