OSS Source Code

[+slx]

Has any source code of any OSS programs ever surfaced? I wondered if one could add integer variables (or other desirable features of other 3rd party BASICS to BASIC XE.

[Rybags]

Not that I know of.

 

Problem with integer variables is often they're just slower in processing. If standard BCD variables are in the equation then conversion to/from BCD is needed for the operation to take place. The space savings is desirable but strings can be used if storing 8-bit values is required - or just POKE into RAM.

[Chilly Willy]

The source code for the original Atari BASIC and floating point package was released - in fact, a whole book was devoted to explaining how Atari BASIC worked, where the bugs were, and how to fix them properly. Using that, integers could easily be added to Atari BASIC. Integer vars in BASIC normally make it MUCH faster as was seen in several other versions that used integer vars as opposed to floating point.

 

http://users.telenet.be/kim1-6502/6502/absb.html

 

Grab all the pages and read this from cover to cover. Anyone who hasn't read this shouldn't be considered qualified to comment on Atari BASIC.

[flashjazzcat]

Great!

 

Integer vars in BASIC normally make it MUCH faster as was seen in several other versions that used integer vars as opposed to floating point.

Well exactly, and the need to convert integer arguments to FP is probably a rare thing anyway. In all my years writing BASIC and TBXL programs I can count the times I actually needed FP on the fingers of one hand. Ninety-nine per cent of the time, integers would have done everything I needed. And if you have 24 or 32 bit integers, you can usually fudge FP output anyway.

[+slx]

Problem with integer variables is often they're just slower in processing. If standard BCD variables are in the equation then conversion to/from BCD is needed for the operation to take place. The space savings is desirable but strings can be used if storing 8-bit values is required - or just POKE into RAM.

I'd suppose they should be faster for things like loops, peeks, pokes, etc., at least if they're single- or double-byte, as a lot less memory manipulation is required. Obviously there is some extra overhead if the interpreter allows type mixing and has to check types and convert before operations, but hat would affect arithmetics only and still allow for faster loops, etc. Type checking could be simplified by toggling a bit in the variable token.

 

BTW I did read "Inside Atari BASIC" around 1984/5 and remember it to be a great read but can't recall every word 30 years later (I lost my copy in the meantime and reading it on an iPad just isn't the same as Compute! spiral binding. If I find a couple of Compute! books from a single seller I'd be very tempted to buy them, but with transatlantic shipping at 20$ for a single book, collecting them from various US sellers is prohibitively expensive.)

 

Wasn't it great that Atari users could get well documented (and explained!) source code for their BASIC and DOS?

[Chilly Willy]

I love that the Atari had well-documented OS and BASIC, and a great hardware manual. It's part of the reason I went with the A8 instead of the CoCo.

 

Mixed types shouldn't be too hard to handle. The operator can automatically call type converters as it pops arguments off the stack, depending on what it expects. For example, if ADD pops an FP and an INT, it would be easy enough to call INT2FP on the INT arg and then do a FPADD. If it popped two INTs, it just does an integer add. I'd make it where it handles all ints the fastest since that's where people expect the speed. FP is already slow, so making recognition of FP args or having to do type conversion slower isn't a big deal.

[Rybags]

Most (all?) variants of Commodore Basic convert the Int to FP, so it executes slower. Throw in the fact that variables aren't tokenized, the space saving is usually negated since each reference to the variable costs an extra byte since the % suffix is required. In the case of arrays the memory saving can usually be realised though.

 

It'd be a non-trivial job to add "proper" int support to any language without it. Seperate int routines are needed to realise speed increase and the problem of mixed int/FP within expressions is still there. Fact is, practically all of the Atari OS FP package is pretty useless therefore decent interpretors like Turbo-Basic use their own.

 

As such, improving a language like Atari or MS Basic essentially gives you something bloated probably 50% or more in size over what you started with, then the question arises "Why didn't I just use Turbo Basic to begin with?"

[flashjazzcat]

Best idea would be to get rid of FP altogether and use the freed up space to add support for longer ints.

[Rybags]

An integer Basic for A8 would be a good idea - given that there's already the 5 or so major variants in use with their various advantages, it'd neatly fill a gap in the market so long it was fast enough.

[+JAC!]

Concerning BASIC I think that the mere arithmetic performacne improvement resulting from "real" INTs alone doesn't count much. Turbo Basic (apart from an extremely fast FP package that makes the difference almost vanish between BCD and INT) also comes with direct line addresses/label and such. So a FOR loop is faster simply because it doesn't have to search for the line of the FOR when it reaches the NEXT. That along acounts to much more than the simple STEP 1 addition.

 

Also quite noteworth here: The TurboBasic Compiler (which comes with TurboBasic for free) has a built-in optimization that detects INT only parts of the code/expressions and does it all without any conversion to FP if possible. "POKE 16,64" becomes "LDA #64:STA 16". c.f. http://www.tmeyer.de/atari/hc_turbo-basic_compiler_info.pdf

 

And that actually is what I consider the best tradeoff: More flexibility during development, more speed in productive code.

[Chilly Willy]

Best idea would be to get rid of FP altogether and use the freed up space to add support for longer ints.

That would certainly be the easiest way to deal with it as well... except for transcendental functions. Trying to add mixed type support wouldn't be as easy, but would be more "fun".

 

Also having the source allows improvements to be made. For example, the issue with FOR/NEXT mentioned - you could extend the code to save the result of the lookup the NEXT op does so that the next time through it's much faster. Things like that.

[phaeron]

The floating-point library doesn't make as much of a difference performance-wise as you might think. My experience with writing and profiling Altirra BASIC is that most programs spend much more time in control structures and the interpreter than in the FP library. Even math-heavy programs spend a decent chunk of time in the interpreter. Floating-point is slow and decimal math is slower, but it's not that slow -- it's generally <300 cycles for an add, and it takes quite a lot of other cycles to execute the statement and expression to get to that add.

 

For example, I've attached a profile of a BASIC program running under Altirra BASIC+OS. Notice that the profile is absolutely dominated by the expression evaluator. This means that having to add code to detect implicit int-to-float conversions is actually a problem as the expression evaluator is actually one of the most performance critical paths in the interpreter. Admittedly, BASIC XE is better optimized though (can't compete with 8K of ROM space).

 

IMO, the next step over TBXL would be to go to JIT -- expanded memory is more common, so just compile to machine code on the fly.

 

[flashjazzcat]

MS BASIC source here, for interest:

 

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

[luckybuck]

Hi flashjazzcat!

 

 

That is great news, thank you.

 

One of my plans is to complete this here:

 

https://atariwiki.org/wiki/Wiki.jsp?page=Articles#section-Articles-SourceCodes

 

in order to create a hybrid Basic version from a) Atari Basic Ver. C, b) Turbo Basic XL, and c) OSS Basic XE on an open source base free to everyone, which can be improved by everyone.

[flashjazzcat]

Sounds great!

 

https://atariwiki.org/wiki/Wiki.jsp?page=Articles#section-Articles-SourceCodes

EDIT: Never mind - my bad. The red links are undefined.

Edited July 15, 2014 by flashjazzcat

[luckybuck]

As I wrote: ...plans is to complete

 

Most of the sources are available, further there is someone here on AA who is in the possession of all OSS source codes.

 

The problem: he has promised to not give it away... :-(

 

Promises have to be kept...

 

On the other hand, there is a high risk, that this get lost. In 1991 the blueprints of the Saturn V rocket got back from the USSR (KGB) to the US...

 

Do we really need this? Or is there a slight chance to learn from the past? Repetitions are so boring...

[ricortes]

I feel like asking "To what end?" Beyond archival/instructional use of course which has a value all its own, is there a need for yet another or a patched BASIC? We already have a ton of BASIC languages. The MMG compiler is Atari compatible and has the option of using INT or FP runtime with it. IOW: In various forms, it already exists.

 

I was pretty sure there was a program to convert the FP line number look up that slows BASIC down to either fixed or INTs. That cures at least one of the problems.

 

I could see a couple of uses, like a stripped down 2k cassette/boot disk BASIC that would give you 46k of program space, but it is hard to come up with a lot of utility. Kind of like having a BASIC with one command "USR()" hehe.

 

Specific to the OSS languages<thread topic>, there just isn't a lot of things that were impossible to do without a bit more speed, or free memory.

[luckybuck]

Hi ricortes!

 

For example: in Basic XE:

 

https://atariwiki.org/wiki/Wiki.jsp?page=Basic%20XE

 

you have more RAM, which you can use.

 

Same is true for the SynCalc 128K-Version. Today 1 MB Ataris are no Problem...

 

In my opinion, there will be no end. If everything is open source, it can be improved and improved and improved...