What Basic 2/3.5/7 should have been?

[orac81]

Continuing a thread from games (connex) that has strayed into programming, see:

viewtopic.php?t=11146

One of those what-if's is whether commodore went the right direction after basic 2. The very early MS Basic offered a floating point interpreter that could run on a 4k altair 8080. But by the time of the 64 they still used the same primitive system, only 2 char var name, slow search for vars and goto targets, no proper int arithmetic, etc.

At that time, priorities were set to cram the most functionality into a given ROM size, possibly at the expense of speed. Often enough, also a quick 'time-to-market' took importance over everything else.

When it comes to scientific applications, you want to do stuff with float, an integer-only BASIC is completely unusable for that! Put the other way round, it's fairly easy to add integer variables for more compact storage on top of a float library, and that had been the design choice of MS BASIC then.

I understand that they took Basic 4 from the Pet 4032, stripped the disk commands out and put it in the Vic20 as Basic 2.0. That was then put in the c64. Then gfx commands were added for Basic 3.5/7, but critically it still only has 2 letter variable names,, no named proceedures/functions, and slow seq search for var names and goto targets. Bank switching made this even slower - a well thought out interpiler could have avoided some of that.

By this time there is the ram/rom for a better approach - you could tokenise long var/proceedure names on line entry, (or when run) giving fast access when used. Numeric constants can be tokenised.

At the time I dug around a bit in the Petspeed compiler, and it was very instructive. It could switch quickly between fast integer and float. It generated a fast single byte pcode for common vars/ops.

I do understand that commodore were tied to what Microsoft delivered. And of course its all moot, a what-if.

In contrast, other systems (hp, atari 800, bbc, apple integer basic) took something closer to an "interpiler" approach.

Not that I know of.

Atari had a bog-standard interpreter, Apple Integer BASIC was somewhat faster but as implied, integer-only and thus out of question for serious stuff. Acorn actually had a very efficient interpreter indeed, developed in house, with later extremely fast re-incarnations on the Acorn Archimedes. However, it also had definitely a bigger ROM size (about 32K for BASIC and Acorn MOS combined) and ran on a 2 MHz 6502, so the comparison is somewhat skewed.

What HP BASIC are you actually referring to?

A full version of that would be tokenising/resolving long var/proceedure names, constants, etc, (even tokenising as each line is typed), offering better structured features, generating something close to pcode.

This is what you got from later versions of Acorn BBC BASIC, but ...

That would have been the thing to fix before implementing those other gfx features in basic 3.5/7.

... BASIC V3.5 and V7 also offered extensions for program structure - IF .. THEN .. ELSE, DO .. LOOP in both, BEGIN .. BEND to enable multi-line blocks within selection structures with V7, trap/error and event handling, the latter which required an own runtime stack instead of sharing that with other stuff on the 65xx hardware stack, which would have made it unfeasible to unwind the stack.

To note, even BASIC V2 already tokenizes the program lines as they are stored in program memory.

I know, but only the main basic keywords. Really i am talking about doing more work to partly compile other parts.
Atari 6502 basic does a much more complete tokenisation of lines on entry, but they messed up other aspects so overall it doesn't run very fast.

If you point to the graphics commands as criticism, the question remains whether any of the 8-bit BASICs would have provided enough performance to do anything like real-time vector graphics. The graphics commands were included so people could do graphics in the supplied high-level language without the need to wrap their brains around machine code to draw things at least at a bearable speed. Nothing more. What you can expect then is something like VICtoria did for the map display, where a selection of empires is drawn from predefined shapes.

...

Further discussion about "what ifs?" in design decisions that had be made in those times and then led to the language implementations we got then should probably go into a new thread in either the General or Programming section.

I am not really criticising gfx features as such, but I believe the internal working of that Basic needed fixing before adding more features. By the time of the +4/128 they had 5-7 years from the original pet basic, a team would have had time to work on it.

As I said, I did start trying to write an interpiler (just in C) that could actually do all this, even with a database storage structure working as each line is entered. Or the program could just compile when run, like a more normal compiler, which does have advantages.

[brain]

I understand that they took Basic 4 from the Pet 4032, stripped the disk commands out and put it in the Vic20 as Basic 2.0. That was then put in the c64.

Can you point to notes about that?
I was under the impression they had BASIC v2 (from the original PET 2001 days) and just used that as the base. I don't remember seeing any remains of them stripping out the B4.0 stuff.

Back to the topic, BASIC 2.0 made sense during the Tramiel era, since the goal was to put just enough to make a complete machine, and let the ecosystem (or CBM) add in the goodies.

BASIC 3.5 and 7 (and 10, I guess, if you include the C65) probably made sense in the post Tramiel era, where the quality and capability of BASIC was a competitive line item for manufacturers. That said, I so wish BASIC 3.5, 4.0, and 7.0 tokenization had been more consistent.

I don't know that I agree the design team should have spent time trying to speed up BASIC by modifying how it worked. I think the goal was still to allow the owner to build some stuff immediately with the built in tool, but graduate to better tools as their needs demanded. Making a fast BASIC is like building a fast lawn mower. It can be done, but few will take advantage. BASIC compilers were the better solution, or using a compiled language or ML.

Jim

[Mike]

To note, even BASIC V2 already tokenizes the program lines as they are stored in program memory.

I know, but only the main basic keywords. Really i am talking about doing more work to partly compile other parts.

"Compiling" is a mis-nomer here, preprocessing stuff is what you mean.

Of course you can shift some stuff to the program entry phase, like preprocessing numeric literals to add them to the stored program text and save runtime parsing them each time they're encountered. That's what Sinclair BASIC did. In a similar fashion, one could add tokens to contain the (jump) targets for any GOTOs, GOSUBs and RESTOREs (provided one refrains from allowing parametric input to them).

However, how do you think all that extra preprocessing would go into the available memory? You'd have needed to increase ROM size by a fair amount, and the extra data needed during preprocessing and the extra data in program storage eat up RAM.

You'd also need a better screen editor, one that dispenses with line numbers. All the new program structures would be a mismatch to still using line numbers.

As I said, I did start trying to write an interpiler (just in C) that could actually do all this, even with a database storage structure working as each line is entered. Or the program could just compile when run, like a more normal compiler, which does have advantages.

It's not clear how that would still run on the target machine. People could simply write their programs in C instead.

In effect, you're asking for what QBASIC did for GW/PC BASIC, that's clear. It just didn't happen.

[orac81]

I understand that they took Basic 4 from the Pet 4032, stripped the disk commands out and put it in the Vic20 as Basic 2.0. That was then put in the c64.

Can you point to notes about that?
I was under the impression they had BASIC v2 (from the original PET 2001 days) and just used that as the base. I don't remember seeing any remains of them stripping out the B4.0 stuff.

Yes I thought that too, but someone who was reverse asm the ROMs for PET basic and VIC20 figured out that it cam from Basic 4.0.

This was the history for the earliest Basic ROMS:

https://www.pagetable.com/?p=46

I will have to dig out the one for Basic 4/vic..

It makes sense. In PET Basic 2 the only way to add commands to was to hack the CHRGOT routine in ZP. I wrote an assembler that did this, turning Basic into a sort of macro asm, but it slows down Basic about 3 fold!

In Basic 4 and VIC Basic you had an Basic Error vector that can be used to add commands to Basic. Also added was the ability to hook software device drivers in RAM, impossible in Basic2.

Incidently I used this to make a thing called the Vic-zx Printerface, a 256 byte routine loads to hi mem and uses the chrset in Rom to drive the cheap sinclair ZX printer through the userport. At the time the zx printer was £59, the Cbm printer near £400. You could do full hires with the zx, whereas the cbm 3022 had 1 udg char, etc. The listing for Connex in PCW jan 83 was done on the zx printer! Anyway that story is for another time, but the bas4 device hooks made it possible.

Back to the topic, BASIC 2.0 made sense during the Tramiel era, since the goal was to put just enough to make a complete machine, and let the ecosystem (or CBM) add in the goodies.

BASIC 3.5 and 7 (and 10, I guess, if you include the C65) probably made sense in the post Tramiel era, where the quality and capability of BASIC was a competitive line item for manufacturers. That said, I so wish BASIC 3.5, 4.0, and 7.0 tokenization had been more consistent.

I don't know that I agree the design team should have spent time trying to speed up BASIC by modifying how it worked. I think the goal was still to allow the owner to build some stuff immediately with the built in tool, but graduate to better tools as their needs demanded. Making a fast BASIC is like building a fast lawn mower. It can be done, but few will take advantage. BASIC compilers were the better solution, or using a compiled language or ML.

Jim

Well I can say when I brought my C128 back then, I noticed the shortcomings that were still not fixed: 2 char var names, no proceedures etc. Acorn/BBC basic had fixed this, with a much smaller budget.
This defect carried through to the cbm compilers, which also didnt have long var names and named subroutines. By contrast bbc basic compilers did. Even the zx81 had long var names!

[Mike]

In Basic 4 and VIC Basic you had an Basic Error vector that can be used to add commands to Basic.

You're probably confusing that with a common method on the Sinclair machines to add commands.

On the CBM, that would actually be the token dispatch vector in ($0308) and the function evaluation vector in ($030A) to use for that kind of stuff.

One can still choose between adding the extension by using a marker character (like "@" is used in MINIGRAFIK) or doing a proper tokenizer and lister as I did for MAXIGRAFIK.

Also added was the ability to hook software device drivers in RAM, impossible in Basic2.

Sorry, what? Of course the KERNAL vectors can be used to implement that kind of programs! That would anyhow be a thing not specific to a language implementation and thus application programming stuff, but rather a OS/KERNAL thing and therefore a case for machine language.

...

In addition to my previous post, about enhanced program structures: you get named procedures, and preprocessed jump tokens with Waterloo BASIC. See here.

Edit:

Even the zx81 had long var names!

The ZX81 also had a far different method of program entry, which effectively already entered the tokenized commands and functions directly on input. With free-form entry (as the screen editor of the 8-bit CBM is), going away from just 2-character variable names requires the user to use blanks as delimiters around reserved keywords.

The common BASIC compilers on CBM 8-bit probably did not include longer variable names, as they were supposed to compile original BASIC programs that were previously tested on the interpreter. As the interpreter would not honour longer variable names (it would alias anything with the same first 2 characters), neither was there need for the compilers to support them.

[orac81]

In Basic 4 and VIC Basic you had an Basic Error vector that can be used to add commands to Basic.

You're probably confusing that with a common method on the Sinclair machines to add commands.

On the CBM, that would actually be the token dispatch vector in ($0308) and the function evaluation vector in ($030A) to use for that kind of stuff.

One can still choose between adding the extension by using a marker character (like "@" is used in MINIGRAFIK) or doing a proper tokenizer and lister as I did for MAXIGRAFIK.

Also added was the ability to hook software device drivers in RAM, impossible in Basic2.

Sorry, what? Of course the KERNAL vectors can be used to implement that kind of programs! That would anyhow be a thing not specific to a language implementation and thus application programming stuff, but rather a OS/KERNAL thing and therefore a case for machine language.

My apologies, I meant PET Basic 2, the common term for the 3032 roms or "upgrade" roms for the 2001. There was no ram vector to trap/extend basic, you had to use CHRGOT, which is horribly slow.

...

In addition to my previous post, about enhanced program structures: you get named procedures, and preprocessed jump tokens with Waterloo BASIC. See here.

Edit:


The ZX81 also had a far different method of program entry, which effectively already entered the tokenized commands and functions directly on input. With free-form entry (as the screen editor of the 8-bit CBM is), going away from just 2-character variable names requires the user to use blanks as delimiters around reserved keywords.

The common BASIC compilers on CBM 8-bit probably did not include longer variable names, as they were supposed to compile original BASIC programs that were previously tested on the interpreter. As the interpreter would not honour longer variable names (it would alias anything with the same first 2 characters), neither was there need for the compilers to support them.

Ok but my whole point is that by the time of the c128, +4, and even c64/v20, cbm should have at least fixed some of this!
bbc basic was delivered by 1981. Atari 800 basic in 1979, and that was billed as an "pre-compiling interpreter", see:

https://en.m.wikipedia.org/wiki/Atari_BASIC

It didnt run as fast as it could have due to 8k cart limit and some other things.

Also the excellent hisoft pascals for nascoms, (in eprom), then spectrum/cpm, bls/turbo pascal for nascom & cpm, all showed you can have a fast full featured float point diskless compiler, certainly well within 64k ram + rom for compiler.

For the c64 there was an memory only fast basic pcode compiler, published on one of the cdu disks (i think it was blitz). If that was in rom, 64k ram would be sufficient for source and pcode. When you come to finalise the program you can discard the source and run pcode only, which would be far more compact and faster than basic2/3.5/7/10. Remember the library overhead now sits in rom.


You would not need to discard line numbers, bbc basic retains them, and they are needed for backward compatibility with earlier ansi/pet basic.

The legend was that Jack Trameil faced down Bill gates, and purchased unlimited rights to use Ms Basic in the PET for $30k.
I think that, sadly, even though they sold Vics, 64s, 128s by the million, they didnt spend sufficient on actually developing the key BASIC software inside those machines.

[Mike]

Atari 800 basic in 1979, and that was billed as an "pre-compiling interpreter", see: https://en.m.wikipedia.org/wiki/Atari_BASIC

Pre-processing numeric literals and replacing variable names by token pointers by no means counts as "compiling" or even "pre-compiling", regardless what Mr. Shepardson said at that time. It shows a viable approach to minimize run-time searches, yes - however the mentioning of 1-byte indizes into both variable names and variable values would indicate to me Atari BASIC only managed 256 different variables at all, which sounds rather limiting?

I had a similar idea quite some time ago (even wrote a manifesto about that), where single character variables would be stored in a static location (26 entries in total - similar to the Super-Numbers mentioned in other threads), and 2-character names would be pre-faced by a token ('variable of type X'), and during start-up of the program be replaced by pointers into the variable space when parsed the first time. Upon editing the program, the original name would be temporarily restored in the stored program text.

Also the excellent hisoft pascals for nascoms, (in eprom), then spectrum/cpm, turbo pascal for cpm, all showed you can have a fast full featured float point diskless compiler, certainly well within 64k ram + rom for compiler. [...]

O.K., but then we're talking about compilers again, where that tool had all the time (within limits) to analyse the program text and eliminate any parsing and search processes typical for interpreted code, and where the result is an executable program, be it in machine code or P-code - both with a runtime library of whatever size.

[...] run pcode only, which would be far more compact and faster than basic2/3.5/7/10. Remember the library overhead now sits in rom.

9 KB "overhead" for BASIC V2. Something needs to be there to get things running. I strongly doubt a compiling solution will fit into the same space. Also, most CBM compilers still make use of the float arithmetic routines in the BASIC interpreter, so they also take what's there.

I have made the observation, that for compute-heavy applications you can get a speed-up of roughly 3 times by directly calling the float routines in the interpreter (having eliminated any parsing, and search processes for variables), see my Mandelbrot plotter for an example. There, I solely replaced the inner loop for said speed-up factor, which then shows for deeper zooms. I left the remainder of the program in MG-enhanced BASIC. For one set of co-ordinates, the untreated version needs 39 hours, the partially translated version needs 14 hours. Eliminating BASIC completely would just reduce the time to 13 hours, hardly worth it.

You would not need to discard line numbers, bbc basic retains them, and they are needed for backward compatibility with earlier ansi/pet basic.

I even know that consideration by quote from the BBC BASIC manuals.

The legend was that Jack Tramiel faced down Bill gates, and purchased unlimited rights to use Ms Basic in the PET for $30k.

Mr. Tramiel purchased an architectural licence, i.e. the right to deliberate alter the BASIC to his liking, yes.

Sadly, even though they sold Vics, 64s, 128s by the million, they didnt spend sufficient on actually developing the key BASIC software inside those machines.

Indeed they sold well as they where, so why put extra work into them, drive up the cost and lower margins?

On the CBM machines people quickly learned that BASIC was good enough for small and medium sized programs and games, and that anything beyond that required machine code. That realization also come to full light for the people on other systems, just a little bit later.

It does not rule out BASIC completely. There's still the case for keeping I/O-bound stuff in BASIC and only do the compute-heavy stuff in machine code. Or, put the other way round, using BASIC to 'script' calls to machine code. That's a technique I employ quite often for my programs on the VIC-20 (and for which above mentioned fractal plotter is a particular example).

[orac81]

I havent dug deep on atari basic, but (from memory) with petspeed the 32 most common vars and 7 common opcodes are combined for a 1 byte pcode, ie "add var1", etc, but vars beyond have 2byte+ representation, you are not limited to 32 vars.

Yes 9k would be too little for a float var 6502 compiler, maybe 16k? By the time of the c16/128 rom was cheap. But once you get over the "hump" of rom overhead there are advantages. The compiled pcode is much smaller than basic source. Some less time critical rom routines can be written in pcode.
Wozs Apple integer basic writes some rom routines in sweet16 pcode, with big savings.
for example the code "v1=v1+v2" in petspeed pcode (from memory) might be something like: "load v1" "add v2" "store v1", so 3 bytes vs asm:
lda v1: clc: adc v2: sta v1
lda v1+1: adc v2+1: sta v1+1
19 bytes!

This whole thread started with observation of the speedup of 3-4 times the blitz/austrospeed pcode compiler gave to my old Connex basic game.
If the vic20 austrospeed was recompiled/relocated to $2001 start, you could have a hires screen at $1000-1fff, and compile your mandlebrot prog with it!

[Mike]

Wozs Apple integer basic writes some rom routines in sweet16 pcode, with big savings.
for example petspeed pcode (from memory) might be something like: "load v1" "add v2" "store v1", so 3 bytes vs asm:
lda v1: clc: adc v2: sta v1
lda v1+1: adc v2+1: sta v1+1
19 bytes!

For the record, I have a freely relocatable port of the Sweet-16 VM in my repository.

Judging from its instruction set, it would indeed give quite some savings on code with lots of pointer arithmetic, and of course be a natural choice for 16-bit integer computing stuff. However, the Sweet-16 VM fell out of favour with later versions of Apple BASIC. Probably they identified the critical parts in the machine code, and retroported those sections with subroutine-threaded code to speed up things.

In MINIMON, for example, there exist a handful of routines that do address arithmetic on a few pointers in ZP, all of which have been factored out into subroutines. The corresponding JSR also only needs 3 bytes.

This whole thread started with observation of the speedup of 3-4 times the blitz/austrospeed compiler gave to my old Connex basic game.
If the vic20 austrospeed was recompiled/relocated to $2001 start, you could have a hires screen at $1000-1fff, and compile your mandlebrot prog with it!

As you can see, I managed to implement all that without using a BASIC compiler: there *is* a hires screen at $1000..$1FFF, provided by the MINIGRAFIK extension. Beyond that, I pin-pointed one single line statement eligible for additional translation to machine code, giving the 3x speed up for the deeper zooms.

The contemporary BASIC compilers did not take a different BASIC start into account, which indeed would have been necessary to reserve memory for the graphics bitmap on the VIC-20. That issue not only thwarts any use of them for hires graphics, it already disallows user defined graphics for any games! The sole exception is where the design is content stuffing a few UDGs into the buffers at 673..767 and 828..1023 - but this then otherwise loses the capability to use inverse characters to access the non-inverted ROM characters, and thus any necessary letters and digits need to be included with the UDG charset. (see also here: https://sleepingelephant.com/ipw-web/bu ... quirements)

[orac81]

I think with apple2 int basic, in 1978 they wanted to move quickly to the "standard" float point ms basic (applesoft basic), and not spend a year or so updating their own basic. Maybe Woz was too busy by then!

The problem with austrospeed is probably solvable - the basic stub and library could be relocated from $1201 to $2001. There is an "decompiler" for austrospeed, so maybe the vic 20 version could be turned back to basic, altered to compile at a location $0e00 higher, then recompile itself to that position.

Some compilers (ie Basic64/128) also support basic extensions like minigrafik, simons basic etc. The extension has to follow certain parameter syntax rules, but it is possible to extend compiled programs that way, and it could be possible to make austrospeed do the same.

[Mike]

The problem with austrospeed is probably solvable - the basic stub and library could be relocated from $1201 to $2001. There is an "decompiler" for austrospeed, so maybe the vic 20 version could be turned back to basic, altered to compile at a location $0e00 higher, then recompile itself to that position.

The question remains whether the runtime library is relocatable. If it is contained as binary blob within the compiler (possibly taken from the original executable), you can't just adapt the decompiled 'source' to compile for higher addresses by changing a few constants.

Some compilers (ie Basic64/128) also support basic extensions like minigrafik, simons basic etc. The extension has to follow certain parameter syntax rules, but it is possible to extend compiled programs that way, and it could be possible to make austrospeed do the same.

Compiler support was not on my priority list when I designed MINIGRAFIK. In an earlier post in another thread, I once pointed out the design decisions behind MG, quoting from there:

MINIGRAFIK implements a minimal set of graphics commands on purpose.

I aimed to include all really necessary and indispensable commands. A programm that uses MG will always need the commands to switch on the graphics, clear the bitmap and return to text mode. Without at least a pixel plot command we'd sorely miss the purpose, no? The line-drawing variant was included because doing lines just with single pixel plots incurs a speed hit that can't be tolerated for most applications - so line-drawing is in, too. At least some applications also require a pixel read function - it's there. Unless one can save and load the hires screen, you really can't take that extension serious (now guess what: screen load/save is *missing* with Super Expander). You can count on that most client programs use nearly all code of MG, so there's no dead code around when it is active.

Any extensions beyond that would only add bloat if they were added to the core of MINIGRAFIK. I excluded colour definition commands, because POKEs to the addresses 646, 36878 and 36879 are entirely sufficient to do the job. Not all programs need to draw circles, not all programs need to print text into the bitmap. Still, in the past I have provided ML libraries that add those functions. Often enough, they can also be implemented as BASIC sub-routines, and still be fast enough for most needs. Not everything needs to be provided as dedicated BASIC command.

That being said, you get all those extra functions with just an extra 1 KB of machine code. There is also support for production code to automatically load and start up the extension first and then load and run a client program in a batch procedure.

In the thread about CONNEX, I already pointed you to VICtoria as an example for a game that employs MINIGRAFIK. Besides using MG for the title screen, for the map display and during the end sequence, the remainder of the program is written in pure BASIC. Most of it is keyboard-driven menu code that spends most of its time waiting for keyboard input. Compiling it would not improve anything.

[brain]

Yes I thought that too, but someone who was reverse asm the ROMs for PET basic and VIC20 figured out that it cam from Basic 4.0.
This was the history for the earliest Basic ROMS:

https://www.pagetable.com/?p=46

I will have to dig out the one for Basic 4/vic..

I found it: https://www.pagetable.com/?p=43

The sad part is that I read (and enjoyed) Michael's writeup years ago when he did it. So, I *KNEW* it was a backport. It such that corrections you learn later don't truly replace the original information.

Sadly, Michael's write up does not include how he fully arrived at this finding, which would be nice to see.

[orac81]

There is a longer writeup somewhere, I did save it.. somewhere..
The rational was that Basic 4 (and kernal) had a lot of bug fixes and improvements (inc important ram vectors for extending basic and adding device drivers via software) so they worked back from that, removing unwanted features (disk commands, etc) to fit it all in 20k vic20 rom.
Odd bits like string garbage collection were much improved with 4.0.

As for compilers/extensions, for a lot a programs there is a big gain in removing much Basic script overhead and using true integer arithmetic in between the calls to the extension. The point I was making was you might hardly have to change minigafik at all, the compiler could provide a way to talk to an extension almost transparently.

[Mike]

The point I was making was you might hardly have to change minigafik at all, the compiler could provide a way to talk to an extension almost transparently.

During operation, all these BASIC extensions call routines in the BASIC interpreter to parse the BASIC program text for parameters. They use the same calls for that as do the other BASIC commands and functions, so parameters can not only be number or string literals, but also be variables or arbitrary expressions.

For a compiler to interwork with that setup transparently would mean providing these argument calls with a mock BASIC text. This introduces quite some inefficiency into the compiler > BASIC extension interface, as that mock BASIC text has to reflect the current value of the parameter, either as number or string literal or as mock variable.

That source of inefficiency could be mitigated by patching all corresponding parameter calls in the BASIC extension, so the compiler need not construct that parsable mock BASIC text on-the-fly. Getting that to work is a procedure that needs to be repeated for every pair of compiler and BASIC extension - and patching the executable of the BASIC extension is not transparent at all.

Finally, a BASIC compiler could simply re-implement the commands of the BASIC extension within its code generator. That approach had probably only been viable for more widespread BASIC extensions, or for those BASIC extensions that were developed in the same software house as was the compiler.

As for compilers/extensions, for a lot a programs there is a big gain in removing much Basic script overhead [...]

BASIC extensions operate under the premise that there exist algorithms, that either would run too slow in BASIC, would need comparatively a lot of statements, or could not even be implemented in BASIC at all - likely, anything that changes KERNAL functionality. If that function could be expressed with a short name, maybe with some parameters, BASIC extensions add this to the pool of available commands.

Of course, implementing the once slowest parts of a non-trivial BASIC program as efficient routines within a BASIC extension then puts the eyes on the remaining overhead.

Compilers operate under the premise that there exists this overhead from parsing and search operations, that most of the overhead can be eliminated by analysing the program text and building an executable for the program that only contains the actual workload. Perhaps even with more efficient implementations of some commands and functions.

These tools speed up the whole program as a result, however compiled code of a routine written in pure BASIC that aims to reproduce the functionality of a corresponding command in a BASIC extension is unlikely to match the speed of the latter. That is because the former still needs to work within BASIC semantics and can't, for example, simply compile X=X+1 as INX.

If compilers and BASIC extensions are orthogonal approaches to increase the efficiency of programs, that would mean to choose the one which does the better job in a given case.

[...] and using true integer arithmetic in between the calls to the extension.

Speaking of MINIGRAFIK and graphics applications; while many graphics algorithms/primitives can well be expressed within the limits of integer arithmetic, quite some algorithms are better done with float - in the sense that they require thoughtful analysis of round-off/overflow/underflow situation to build an integer-only implementation and writing the code in float is a more natural choice.

In short, while there exist applications that allow for the sole use of integer arithmetic in the program, not all do.