If I read the last post correctly Owl Basic will permit a space between the keyword ‘proc’ and the procedure name, i.e. def proc DoThis, rather than def proc_DoThis. This is a welcome change and has one very interesting consequence.

I use BBC4W with an external editor, PSPad. This editor allows the use of user produced syntax files and the control over keyword colouring and font. As it operates on whole words it cannot colour the keywork ‘proc’ in proc_DoThis. Allowing a space after proc will allow syntax colouring to be used.

PSPad allows an external compiler (or interpreter) to be called so it will only be a matter of pointing it at the Owl Basic compiler.

If you are willing to go a little bit further in dropping complete compatibility with the ARM interpreter the way functions are defined and called would benefit from a bit of tidying up. In particular an ‘endfunc’ and a specific keyword to return a value from the function would bring it closer to modern ways of doing things. It might mean changing ‘return’ for variables passed by reference to ‘ref’.

Some BBC BASIC constructs, notably BB4W pointer syntax and also indirection operators may result in the generation of code which is required to be marked as ‘unsafe’ to the runtime. I’m finding it a fine line between implementing a language compiler and implementing a BBC Micro or RISC OS emulator. I’m trying to stay true to the language whilst still providing something that is in some sense useful and can run real programs. Right now I’m working on improving the type inferencing system to see if its possible to determine at compile time whether indirection operators index into a pre-allocated DIM block% 1024, which is safe, or whether they just manipulate some system memory directly, which is unsafe. One of my test programs is Acornsoft Sphinx adventure which seems to store data in the BBC MOS Econet workspace – to support cases such as think I’ll be supporting a compile-time flag or pragma which fakes a BBC Micro 32 kB (or larger!) memory map, which is peanuts these days. On a related note PAGE, HIMEM, TOP and LOMEM will probably return dummy but consistent values without much meaning, since I’m not reproducing the BBC BASIC stack or heap structures.

There definitely won’t be an inline assembler for native machine code; however, in the spirit of previous incarnations of BBC BASIC an assembler for the host system will be provided, which in this case will be the stack virtual machine code CIL. In practice assembly will be delegated to the Microsoft or Mono tools for that purpose. That said, if you need to call into native code I think I’ll have SYS doing the equivalent of a CLR P/Invoke. I’ve already had the compiler running on architectures other than IA-32 – its developed primarily on an amd64 computer but I’ve also had it running on my 64-bit Sunblade SPARC under Mono! It should, in theory also run unchanged on the ARM or PowerPC CLR implementations…

Unless you have done so already, do you intend to implement some or all of BBC BASIC for Windows’ features (not available in ARM BBC BASIC 5 and certainly not in 8-bit BBC BASIC II) such as structures, the ^ ‘address of’ operator, the function form of the DIM keyword DIM() which – amongst other things – returns the size of an array or structure. And will it include an inline IA-32/x86 assembler?

Regards,
David.

Congrats by the way. The first executable is always a good milestone to reach.