slightly OT: a simple Benchmark

[dp11]

To make things even quicker as most of the time no key will be in the buffer use the z flag instead of carry as you get that for free in the first test. . Can the returned key value be zero?

[drogon]

dp11 wrote:

To make things even quicker as most of the time no key will be in the buffer use the z flag instead of carry as you get that for free in the first test. . Can the returned key value be zero?

Not quit sure whos message this is in reply to... However in my system, it do use the Z flag to indicate presence (or lack of) a character waiting to be read (mostly because it's simply the count of characters available). For whatever reason I just assumed that was the way it is - so when EHBasic started to be weird, I looked at the EHBasic code - it requires the C flag. It would be no big deal to change EHBasic but then every other monitor/bios wouldn't work with it. So I modified my "bios" to set both C and Z appropriately - so my existing code doesn't break and EHBasic is happy.

-Gordon

[GaBuZoMeu]

floobydust wrote:

Well, I'm quite late to the party on this one, ...

no, no, not too late, never

Table is updated. Thank you for your numbers and for the sources!


Regards,
Arne

[kc5tja]

I'm not sure if this has been mentioned earlier; but, at least in CBM BASIC, integer variables are always slower than floating point variables. This is because CBM BASIC (in order to fit in 10K of ROM) converts integers into floats before operating on them, then back again to store its results into a variable. See https://www.youtube.com/watch?v=wo14rDnGUbY for a nice demonstration.

[BigEd]

kc5tja wrote:

... in CBM BASIC, integer variables are always slower than floating point variables.

Interesting, I didn't know that. Trying the same simple loop as in the video, I see Acorn's BBC Basic has a healthy speedup of nearly 60% when incrementing an integer variable as opposed to a float.

[GaBuZoMeu]

Thank you kc5tja.

I briefly checked the behaviour of my SYM-(Microsoft)-Basic. It appears to behave like the CBM Basic. A slight speeddown (I faintly remember that I thought integers weren't supported all - perhaps because there was no significant speed chance), 7 bytes per single variable (name + value), but 2 bytes / variable when being part of an array (plus overhead of course).

Another reason why Basic had no good reputation back in those days.

[GaBuZoMeu]

I inspect this behavior a little more. Trying to use the same as possible source for integer or float I use a direct translation from the VTL02C version:

Code: Select all

 90 DIM V%(09)
 100 PRINT"RANGE :";
 105 INPUTV%(0)
 110 PRINT"min. Diff.:";
 115 INPUTV%(1)
 120 V%(9)=3
 130 V%(2)=1
 140 V%(2)=V%(2)+2
 150 V%(3)=1
 160 V%(3)=V%(3)+2
 165 V%(8)=V%(2)/V%(3)
 170 IF V%(8)*V%(3)=V%(2) GOTO 210
 180 IF V%(2)>(V%(3)*V%(3)) GOTO 160
 190 IF V%(2)>=(V%(1)+V%(9)) GOTO 230
 200 V%(9)=V%(2)
 210 IF V%(0)>V%(2) GOTO 140
 220 PRINT"Keine Loesung"
 225 GOTO 260
 230 PRINTV%(2);
 240 PRINT" ,  ";
 250 PRINTV%(9);
 260 PRINT""
 270 END

All variables are part of an array - the only way to assure they use two bytes each. Running this for the first gap (1000 : 20) took 111s (!) on the 1MHz 6502 - nearly twice the time of the original approach. That is worse than I thought.

Changing V% to V and line 165 to "165 V(8)=INT(V(2)/V(3))" gives the float version - it took 106s to finish.

That means there is no integer math available. It looks as if they (Microsoft) even omit any gains from easier indexing of integer arrays.

If anyone wonders why Forth becomes that popular those days - well, here is one reason.

[drogon]

GaBuZoMeu wrote:

That means there is no integer math available. It looks as if they (Microsoft) even omit any gains from easier indexing of integer arrays.

If anyone wonders why Forth becomes that popular those days - well, here is one reason.

The gain was storage for arrays. Half the memory needed for 2-byte ints over 4-byte floats, although some BASICs weren't quite like that - BBC Basic - 5 bytes for a float, 4 bytes for an integer so the memory savings weren't that significant.

The real thing here is the somewhat semi-typed nature of BASIC - and it all depends when "those days" were - The Jupiter Ace - a Forth only home computer sold in 1982 didn't really sell that well. Under 6000 units sold and despite one colleagues attempts to get me to do some work in Forth a year or 2 later, I used BCPL instead as the best thing to C on the 6502 systems I was using then.

Current interpreted BASICs have the same issues as back then - to make sure you do a calculation in integer math, you need to make sure all variables, constants, etc. are integer, or you do what C does and promote everything to double, then do the calculation.... My own BASIC simply doesn't have an integer data type right now.

-Gordon

[GaBuZoMeu]

Basic and Forth both do not require a sort of operating system. That was their advantage and entry card to these SBCs like KIM, SYM, and others and to quite a bunch of "home computers" a little later as well. Once you have discs you have an OS and perhaps a compiler. But such sophisticated systems are usually out of reach for hobbyist and enthusiasts.

I have never heard of BCPL for the 6502. Was it a cross compiler or running on 6502 hardware? Are there any remains of it?

-Arne

[drogon]

GaBuZoMeu wrote:

Basic and Forth both do not require a sort of operating system. That was their advantage and entry card to these SBCs like KIM, SYM, and others and to quite a bunch of "home computers" a little later as well. Once you have discs you have an OS and perhaps a compiler. But such sophisticated systems are usually out of reach for hobbyist and enthusiasts.

I have never heard of BCPL for the 6502. Was it a cross compiler or running on 6502 hardware? Are there any remains of it?

-Arne

There is a native BCPL system that runs on the BBC Micro. The 16K ROM had the bytecode interpreter, command-line interface and some utilities - the disk had the compiler and other utilities. It was relatively fast from what I recall - faster than BASIC, but only 16-bit integers. I spent a couple of years with it in the early/mid 80's. I'm just about to give it a go on my Ruby 6502 system - need to tweak the filing system first though.

As for BASICs needing (or not) an OS - It's a tricky one by the time you reach 1981/82 as BBC Basic did need an underlying OS to fully function. It is a 16K ROM, but doesn't include stuff that other BASICs might have as part of their ROM - like character/screen IO, filing system, sound, joystick, network and everything else that goes with the BBC Micro - the OS was another 12K of ROM with things like filing systems being yet another 8-16K of ROM. ... I've implemented enough to get BBC Basic to run on my system, but not everything like graphics & sound - yet.

-Gordon

[GaBuZoMeu]

Ah, ok the BBC micro. This one somehow escaped from my "monitoring" - it wasn't much a highlight in German computer magazines. They are mostly focused on Atari and Commodore (which continues with their 16 bit machines). The inner strengths of the BBC micro remains secrets - at least to me. I assume I would have bought one if I have had heard more (and perhaps more enthusiastic) informations - just because I started on a 6502 . But back then I bought a 6809 board and extents it to a floppy based system. There were Pascal and C compilers available (Basic and Forth as well). Using the C-compiler was a nightmare - not enough memory - but Pascal works well and the programs performs quite well. Once there using interpreters appears like backsteps.

[BigEd]

Because it's such an interesting machine, and important at least in the UK, I wrote an introductory post about it:

• Acorn's BBC micro - some resources

[GaBuZoMeu]

Hello BigEd,

it's an exceptional concise introductory you have assembled there - many thanks.

[BigEd]

Thanks for the kind words!

[faicuai]

GaBuZoMeu wrote:

A question about execution speed comparisons viewtopic.php?f=5&p=60986#p60969 causes me to present a table where I have noted the execution speed of various computers running a simple program. In order not to stress the original topic I moved to this place.

Code: Select all

                                    B A S I C - B E N C H M A R K  (from BASBENCH.TAB, 28.08.93)
                                    =============================

┌───────────────────┬──────────────────────────────╥─────────────────────┬────────────────────────────┐
│		EINGABE      │          ERGEBNISSE          ║          EINGABE    │          ERGEBNISSE        │
│A:    1000 ,  20   │    907  ,      887  ,    20  ║  D:   32000 ,  50   │  19661  ,    19609  ,    52│
│B:    2000 ,  30   │   1361  ,     1327  ,    34  ║  E:   32000 ,  70   │  31469  ,    31397  ,    72│
│C:    9999 ,  35   │   9587  ,     9551  ,    36  ║  F:  500000 , 100   │ 370373  ,   370261  ,   112│
└───────────────────┴──────────────────────────────╨─────────────────────┴────────────────────────────┘

Using modulo instead of (C%\D%)*D% was the last step:
[code]1  REM Basic-Bench á la SYM etc.
2  REM *** Integerversion + Modulofunktion ***
10 ZS% = 3: INPUT A%,B%
20 FOR C% = 3 TO A% STEP 2
30 FOR D% = 3 TO SQR(C%) STEP 2
40 IF C% MOD D% = 0 THEN 80
50 NEXT D%
60 IF C%- ZS% >= B% THEN PRINT C%,ZS%,C%-ZS%: GOTO 10
70 ZS% = C%
80 NEXT C%
90 PRINT "keine Lösung gefunden !": GOTO 10

Cheers
Arne[/quote]

Atari 800 & 800XL:

Straight port of above code into 1983 OSS Action, typed in, compiled and ran on-cartridge:

Results in frames (@59.92 frames/sec), and Antic DMA=OFF (max. 6502 cycles):

Test 1:   1.2850 secs (77 frames)
Test 2:   2.2196 secs (133 frames)
Test 3: 32.0761 secs (1922 frames)
Test 4: 85.8812 secs (5146 frames)

Could have effortlessly attained those results 38 years ago... ;-)