Introduction to BBC BASIC

[John_Spikowski]

Looking good D!

[ZXDunny]

And the reason I am hesitant to make a submission, as I would be using native code and doing so in BBC BASIC V on RISC OS.

Unless you want to use embedded assembler code, it ought to be relatively easy to write it in 'generic' BBC BASIC so that it will run in BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Matrix Brandy, as well as ARM BASIC V. It won't show off the full potential of the language, since it wouldn't be benefitting from the enhancements in my versions, but at least it means your submission can be tested on more common platforms.

How do I do that? How do I create a window, handle menus, handle Window Manager events, handle messages, etc in a way that is OS independant without using libraries, while maintaining compatibility with RISC OS?

Just... Don't?

I mean, what is a window? It's a region of memory that you draw to. The only OS-dependent code would be getting and displaying that surface and BBC BASIC uses SDL2 for that, I'd imagine. Everything else such as mouse movement/clicks, keyboard usage should be exposed to the user in any decent BASIC. Does BASIC-V allow you to track the mouse?

A Menu is just another window with some text on it. You can draw fancy shadows and stuff on it if you like, too. There's no limit to what you can do if you're prepared to start writing pixels. And you can do all that without calling the OS.

[RichardRussell]

How do I do that? How do I create a window, handle menus, handle Window Manager events, handle messages, etc in a way that is OS independant without using libraries, while maintaining compatibility with RISC OS?

By doing everything in BASIC! BBC BASIC is more than capable of implementing the full set of GUI features that you describe without calling upon any OS functionality. As I think you know, both IDEs supplied with BBC BASIC for SDL 2.0, my 'SDLIDE' and Andy Parkes' 'BBCEdit', are written entirely in BBC BASIC; that way I achieve the level of cross-platform compatibilty that I want (Windows, MacOS, Linux). Those IDEs have menus and toolbars and status bars and a program editor pane and....

As far as using libraries is concerned, that's OK so long as they are BBC BASIC libraries. Admittedly my 'dlglib' library, which provides much of the GUI functionality needed by SDLIDE (pushbuttons, radiobuttons, checkboxes, listboxes, comboboxes etc.) won't run in ARM BASIC V because it makes use of features like structures that are more recent. However it needn't: if you were really keen you could replace all the references to structures and other non-ARM BASIC features with 'older' equivalents that would be compatible.

Once upon a time BBC BASIC simply wasn't fast enough to create a fully-fledged IDE with acceptable performance, but that's not the case any more. Even on the Raspberry Pi (3) my SDLIDE runs acceptably fast. I know this is controversial, but I feel strongly that having to offload functionality such as this to the OS (such as the RISC OS Wimp or Windows common controls or a Linux toolkit like QT or GTK) represents a failure of the language. Writing the IDE in BBC BASIC is one way of demonstrating its capability.

[RichardRussell]

I mean, what is a window? It's a region of memory that you draw to. The only OS-dependent code would be getting and displaying that surface and BBC BASIC uses SDL2 for that, I'd imagine. Everything else such as mouse movement/clicks, keyboard usage should be exposed to the user in any decent BASIC. Does BASIC-V allow you to track the mouse?

A Menu is just another window with some text on it. You can draw fancy shadows and stuff on it if you like, too. There's no limit to what you can do if you're prepared to start writing pixels. And you can do all that without calling the OS.

Your message crossed with mine, but we're both saying the same thing. Yes BBC BASIC (including the ARM BASIC preferred by DavidS) exposes everything needed such as mouse and keyboard activity, and the graphics functionality already support things like viewports. My versions do have a few enhancements that help (such as being notified of mouse clicks with an 'interrupt' rather than having to poll) but these are things I'm sure David could work around.

[John_Spikowski]

Any chance the both of you could collaborate on a submission?

[RichardRussell]

Any chance the both of you could collaborate on a submission?

If you are happy to accept an existing program, rather than something written specifically for the challenge, then my SDLIDE.bbc meets the requirements as I understand them:

Menu: YES
Toolbar: YES
Rich Text edit control: Not Rich Text but Unicode compatible and with syntax highlighting and auto-indenting
Status line: YES
Interface with the Open, SaveAs and Font select predefined dialogs: YES, and others (custom, not "predefined")
Find and GoTo popup dialogs: Find, yes, but currently no GoTo. Could add if required.
Search and Replace: YES
App icon: YES
Copy / Cut / Paste menu options: YES
Hotkey accelerators: YES (if I understand what you mean)
Scintilla editor control replacement for rich edit: NO

Simply installing BBC BASIC for SDL 2.0 on Windows, MacOS or Linux gives you this program in the examples/tools/ directory:; it's one of the IDEs that you can choose on startup. It's written in 100% BBC BASIC code (there are a few SYS statements to access OS functionality such as the clipboard). It's a little over 4000 lines and 100 Kbytes.

[John_Spikowski]

It sounds close enough to me. Could it be used to edit non-BBC BASIC?

I'm sure I could pickup a few tricks from your editor for the ScriptBasic IDE on working on.

[RichardRussell]

Could it be used to edit non-BBC BASIC?

The syntax colouring and indentation are BBC BASIC-specific, of course, and there is a line-length limit of about 250 characters. Apart from that it will probably be OK with source code for a different BASIC (e.g. ScriptBasic), you did ask for a 'code editor' after all. But it's not really suitable for general purpose text editing, for example it will be confused by lines starting with a numeric digit because it will assume it's a line number, and it doesn't like high-bit-set characters unless in quoted strings. So, the answer is "to an extent".

[John_Spikowski]

The goal is to show how desktop GUI is done. The editor challenge is just the stage for that goal.

The idea seems to have sparked the interest of the mother ship as a course is being offered on this topic.

[RichardRussell]

The goal is to show how desktop GUI is done. The editor challenge is just the stage for that goal.

You can do whatever you like with my program (SDLIDE.bbc) and the associated library (dlglib.bbc). Both are written entirely in BBC BASIC and there is no reliance on any external GUI library, framework or toolkit. There are only a few direct calls to the OS, for things such as accessing the clipboard (which is obviously useful for interworking with other apps) and these are mostly non-essential. The program and library will run in both BBC BASIC for SDL 2.0 (on Windows, MacOS and Linux) and BBC BASIC for Windows which demonstrates the degree of OS-independence.

I would really like to see a comparable ScriptBasic solution, i.e. one which doesn't call upon any off-the-shelf GUI library. That would be a better demonstration of the capabilities of the language than anything I've seen so far.

[Heater]

RichardRussell,

I would really like to see a comparable ScriptBasic solution, i.e. one which doesn't call upon any off-the-shelf GUI library. That would be a better demonstration of the capabilities of the language than anything I've seen so far.

I don't want to pick on you in particularly but this kind of statement drive me crazy.

You see, in my mind there are programming languages and then there are run times/libraries that they use.

Programming languages have a lexicon, a syntax and a semantics. Think program structures like "=", "if", "for", "while" etc and all the details of the language. A programming language has a definition and exists outside of any particular implementation.

Then there are all the libraries, modules, etc that can be used from the the language. Think "printf()" or "Window.show()". Whatever. Here is where the abstract language meets the real world of input/output and such like.

In my simple mind languages and libraries/modules/run-time facilities are two totally different things. For example I can use the C language without any of the C standard library, people program the Arduino in C++ without ever knowing about the Standard Template Library or libstdc++.

I noticed that those in "interpreter land", especially in "BASIC land" almost never make a distinction between the language they are promoting and the libraries/modules etc that come with the run-time system that implements it.

Is it so that they don't understand the concept of a programming language as an independent thing separate from any actual implementation? Is it too abstract? Or do they choose to make these ideas dependent on each other? Is this why there are so many variants of BASIC, every implementation had to add/subtract from the language definition in order to fit the run-time implementation they were building?

The Python guys seem to have finally understood this after many years. For example changing the language keyword "print" into thing outside of the language itself "print()"

So, to my simple mind, ScriptBasic and BBC BASIC and the other million BASICs out there would all use the same language syntax and semantics, they could all use each others libraries and modules. But this is not so. And hence this discussion going on here.

Just wondering.

[DavidS]

@RichardRussell:
Thank you for the reply. As I understand the challenge it is to write an editor that actually uses the Window Manager that is native to the desktop Operating System, so based on my understanding I do not feel that writing the whole thing in BBC BASIC by drawing everything would meet the criteria.


Though I am a bit bussy working on a test program at this time, to compare the speed of linux and RISC OS.

Which brings up a question: What subset of the ARM AARCH32 ISA does your BBC BASIC support for assembly? And to verify, your assembler uses the same OPT, O%, P%, and L% meanings (and OPT flags) as RISC OS BBC BASIC V, correct? I ask because more people are likely to have your BBC BASIC on Linux than are likely to have asasm on Linux and I want the program to use the same means of assembling on both platforms.

[Heater]

As I understand it, the challenge is posed in such a way that only solutions that use ScriptBasic would qualify.

Rather like the RISC OS challenge in another thread, that only wants to compare the few things RISC OS can do against rivals

[DavidS]

As I understand it, the challenge is posed in such a way that only solutions that use ScriptBasic would qualify.

Rather like the RISC OS challenge in another thread, that only wants to compare the few things RISC OS can do against rivals

You should have posed that in the other thread. I think ScriptBasics challenge is quite suitable to any language.

And albeit off topic:
The challenge you speak of is limited by what Linux can provide AS AN OS (not a tone of libraries), if the limits were on the RISC OS side much more could be tested. Same reason that OpenGL is left out of that one, as OpenGL is not part of the OS in either case (though both can do it).

[Heater]

DavidS,

You should have posed that in the other thread. I think ScriptBasics challenge is quite suitable to any language.

Nope. Anything using HTML, CSS, Javascript has been specifically disallowed.

And albeit off topic:
The challenge you speak of is limited by what Linux can provide AS AN OS (not a tone of libraries), if the limits were on the RISC OS side much more could be tested. Same reason that OpenGL is left out of that one, as OpenGL is not part of the OS in either case (though both can do it).

Being off topic I will answer in your RISC OS challenge thread.

[RichardRussell]

I don't want to pick on you in particularly but this kind of statement drive me crazy.

Sorry, but you are missing the point. The whole purpose of a challenge, surely, is to be able to make some judgement about the strengths and weaknesses of one language compared with another. An excellent example is Rosetta Code, which lists implementations of many programming 'tasks' in many different languages, and by comparing those implementations one can assess the suitability of a language for a task.

Now imagine the situation when the task in question is available in an off-the-shelf 'external' library, which works very well, and you allow that to be used. Inevitably virtually every implementation, in every language, is going to consist of code which loads that library, calls the relevant function(s) and returns the results. What does that tell you about the suitability of the language to the task? Nothing! It tells you only how it calls functions in a library.

That is the situation we have here. I'd like to know how good ScriptBasic is at things like creating drop-down menus, tracking mouse movements and clicks, editing text entered from the keyboard, scrolling the contents of a window etc., and I want to know how fast it can do these things. The GUI code editor challenge would give me a good insight if implemented solely in native ScriptBasic code and libraries. But if it's just a wrapper around Qt or GTK or any of the other GUI library/toolkits I am not going to learn anything about how suitable ScriptBasic would be for a similar task that doesn't have an off-the-shelf solution.

I noticed that those in "interpreter land", especially in "BASIC land" almost never make a distinction between the language they are promoting and the libraries/modules etc that come with the run-time system that implements it.

I hope you are not including me in that generalisation. I am absolutely clear about that distinction. Indeed I'm not even sure it's possible to have spent more than 37 years intimately concerned with the specification and implementation of a programming language, on multiple platforms, OSes and CPUs, without having such an understanding.

[Heater]

RichardRussell,

Sorry, but you are missing the point.

No. I am not.

Now imagine the situation when the task in question is available in an off-the-shelf 'external' library, which works very well, and you allow that to be used. Inevitably virtually every implementation, in every language, is going to consist of code which loads that library, calls the relevant function(s) and returns the results. What does that tell you about the suitability of the language to the task? Nothing! It tells you only how it calls functions in a library.

Exactly.

That is exactly the issue faced in the fibo challenge. The idea of the challenge is to see some not insignificant code in the language as it tackles the problem. Not just a simple call to a library.

I hope you are not including me in that generalisation. I am absolutely clear about that distinction. Indeed I'm not even sure it's possible to have spent more than 37 years intimately concerned with the specification and implementation of a programming language, on multiple platforms, OSes and CPUs, without having such an understanding.

I don't mean to.

It's just that when someone uses the word "language" to refer to the programming language and the run-time environment it operates in and all the features that implementation provides via modules/extensions whatever, then they start to fall into that generalization.

Maybe I'm just being picky about the use of words. But as we see "BASIC world" consists of a thousand different, incompatible, programming systems that all some how hint at using the same language. Clearly they do not.

[RichardRussell]

It's just that when someone uses the word "language" to refer to the programming language and the run-time environment it operates in and all the features that implementation provides via modules/extensions whatever, then they start to fall into that generalization.

It's all in the context. If you ask me to code some particular task 'in BBC BASIC' you don't mean that I am not allowed to use the libraries that are supplied as standard with that language (especially given that they are themselves coded in BBC BASIC), do you? That would be as silly as asking for a solution in C that didn't call the CRT, which would disallow even (for example) the square root function! On the other hand if you are talking about comparing the syntax of the WHILE loop between one 'language' and another, then you are clearly using the term in a more precise sense.

I really don't think many people are confused by this. 'Language' can perfectly well be used in both senses, with the context informing which is being referred to. If you want me always to say "language and its associated libraries" every time to avoid ambiguity, you're out of luck (and to be fair I did on at least one occasion add that specific clarification in this thread).

[RichardRussell]

As I understand the challenge it is to write an editor that actually uses the Window Manager that is native to the desktop Operating System

John said that my native BBC BASIC program appears to meet the terms of the challenge, so that is apparently not the case.

What subset of the ARM AARCH32 ISA does your BBC BASIC support for assembly?

Obviously most of my editions of BBC BASIC don't run on an ARM CPU (Windows, MacOS and Linux, with the exception of Raspbian) or run in 64-bits on an ARM (iOS) so in those cases the question is meaningless. The only 32-bit ARM editions are for Raspbian and (currently) Android; in those editions the subset of the ARM instruction set supported by the assembler is similar (but not identical) to that in ARM BASIC V. There is currently no support for Neon instructions or any of the other extensions; I would like there to be but it needs somebody with a better understanding of the CPU than I have to add them.

And to verify, your assembler uses the same OPT, O%, P%, and L% meanings (and OPT flags) as RISC OS BBC BASIC V, correct?

As far as I know, yes. If there are differences between the way ARM BASIC V uses them and the way (6502) BASIC 4 does, quite possibly I haven't incorporated those changes. Not having ever owned or used a RISC OS machine I have very little experience of ARM BASIC.

For reference, in 64-bit editions of BBC BASIC (which currently means the MacOS and 64-bit Linux editions) the 'program counter' is Q%:P% (i.e. considering the pair as a 64-bit address, Q% holding the MS 32-bits and P% the LS 32-bits) and the 'limit' is similarly M%:L%. There is no 64-bit equivalent to O%.

[DavidS]

@RichardRussell:
Thank you for the information. It sounds like I should have no trouble using the BBC BASIC assembler on your implementation.

So I will provide the template, as well as the RISC OS version of my code in BBC BASIC ARM Assmebly , so that the needed tools are easily available on both RISC OS and ARM Linux Distros.

On the GUI Challenge:
That does seem a bit odd, though I will look closer at that.

[John_Spikowski]

IUP has an OpenGL forms API that reminds me what you guys are thinking of doing in BBC BASIC. I'm looking forward to see what you guys come up with.

[DavidS]

IUP has an OpenGL forms API that reminds me what you guys are thinking of doing in BBC BASIC. I'm looking forward to see what you guys come up with.

Well I will already tell you it is a little more work than doing it inside of an existing Window Manager.

[RichardRussell]

It sounds like I should have no trouble using the BBC BASIC assembler on your implementation.

There's an assembler 'Hello world!' program supplied with BBCSDL which should give you an idea of whether it will be suitable. Apart from the selection of appropriate source code for the CPU (64-bit x86, 32-bit x86 or 32-bit ARM) hopefully it will hold no surprises. You can ignore, for your purposes, the unfamiliar 64-bit integers code%% and limit%%, they are irrelevant for 32-bit ARM:

Code: Select all

      ON ERROR IF ERR=17 CHAIN @lib$+"../examples/tools/touchide" ELSE MODE 3 : PRINT REPORT$ : END
      VDU 23,22,640;500;8,20,16,128+8
      OFF

      DIM limit%% -1, code%% 100, limit%% -1
      FOR pass% = 8 TO 11 STEP 3
        IF @platform% AND &40 THEN
          ]^P% = code%%
          ]^L% = limit%%
          [opt pass%
          .hello
          sub rsp,40
          mov rbp,"oswrch"
          lea rbx,[rel asciiz]
          .loop
          mov al,[rbx]  ; get next char
          inc rbx       ; bump pointer
          cmp al,0      ; is it a NUL?
          jz done       ; if so, exit
          movzx ecx,al  ; for Windows &
          mov edi,ecx   ; System V ABIs
          call rbp      ; output char
          jmp loop      ; continue
          ;
          .done
          add rsp,40
          ret
          ;
          .asciiz
          db "Hello world!"
          dw &0A0D
          db 0
          ]
        ELSE
          P% = code%%
          L% = limit%%
          [opt 0:nop:]
          CASE P%?-1 OF
            WHEN &90:
              [opt pass%
              .hello
              push esi
              mov esi,asciiz    ; pointer to text string
              .loop
              lodsb             ; get next character
              cmp al,0          ; is it a NUL ?
              jz done           ; if so, exit
              call "oswrch"     ; output character
              jmps loop         ; continue
              ;
              .done
              pop esi
              ret
              ;
              .asciiz
              db "Hello world!"
              dw &0A0D
              db 0
              ]
            WHEN &E1:
              [opt pass%
              .hello
              push {r8-r9,lr}
              ldr r8,oswrch
              adr r9,asciiz     ; pointer to text string
              .loop
              ldrb r0,[r9],#1   ; get next character
              cmp r0,#0         ; is it a NUL ?
              popeq {r8-r9,pc}  ; if so, exit
              blx r8            ; output character
              b loop            ; continue
              ;
              .asciiz
              equs "Hello world!"
              equw &0A0D
              equb 0
              ;
              align
              .oswrch
              equd "oswrch"
              ]
          ENDCASE
        ENDIF
      NEXT pass%

      PRINT
      CALL hello

[DavidS]

Looks good from here. With the possible exception of the means of making a system call. Is using SWI 0 with R7 having the call number still allowable for Linux System Calls from the assembler in you BBC BASIC?

Also on the x86 side of your example:
Interesting mix of 64 and 32 bit regs used. You are using the REX prefix byte and size overide prefix byte a good bit there. I may not do much x86 stuff anymore, though I still remember a lot of it (including the AMD64 stuff, from before Intel licensed it, still the same today).

[RichardRussell]

Is using SWI 0 with R7 having the call number still allowable for Linux System Calls from the assembler in you BBC BASIC?

My understanding is that SWIs are kernel calls in Linux and therefore not usable from user-mode code; is that not right? Certainly I've made no specific provision for them, I'm assuming that all calls into Linux will be via functions in the C runtime library or other shared libraries that are available to a program running with ordinary user permissions (which BBC BASIC normally will be).

Interesting mix of 64 and 32 bit regs used.

In x86-64 mode 32-bit registers are still the default (whenever you write to one the high 32-bits of the equivalent 64-bit register are zeroed). I presume this was done because it's also the convention used by most C-compilers: an int is 32-bits even in 64-bit mode. So you save a prefix byte by accessing a 32-bit register rather than a 64-bit one, if you don't need the full 64-bits. I think the code I posted is optimal in this respect:

Code: Select all

000000000D40231C                      .hello
000000000D40231C 48 83 EC 28                     sub rsp,40
000000000D402320 48 BD 50 1F 41 00 00            mov rbp,"oswrch"
000000000D402327 00 00 00
000000000D40232A 48 8D 1D 1A 00 00 00            lea rbx,[rel asciiz]
000000000D402331                      .loop
000000000D402331 8A 03                           mov al,[rbx]  ; get next char
000000000D402333 48 FF C3                        inc rbx       ; bump pointer
000000000D402336 3C 00                           cmp al,0      ; is it a NUL?
000000000D402338 74 0C                           jz done       ; if so, exit
000000000D40233A 0F B6 C8                        movzx ecx,al  ; for Windows &
000000000D40233D 89 CF                           mov edi,ecx   ; System V ABIs
000000000D40233F FF D5                           call rbp      ; output char
000000000D402341 E9 EB FF FF FF                  jmp loop      ; continue
000000000D402346                                 ;
000000000D402346                      .done
000000000D402346 48 83 C4 28                     add rsp,40
000000000D40234A C3                              ret
000000000D40234B                                 ;
000000000D40234B                      .asciiz
000000000D40234B 48 65 6C 6C 6F 20 77            db "Hello world!"
000000000D402352 6F 72 6C 64 21
000000000D402357 0D 0A                           dw &0A0D
000000000D402359 00                              db 0