Work continues on the BASIC assembler enhancements. After spending some time learning how to use ObjAsm and the ROOL build tools effectively, the past week I've been suffering with a virus (of the human kind) which has slowed development to a crawl.
So far I've created a new optimised and assembler friendly version of all the pattern and lookup tables via ObjAsm macros in an automated fashion from the BASIC code. This makes it easy to update them as I simply re-run the BASIC application. The pains with the existing Acorn BASIC source code persist, so the plan is to add a branch from the existing code when a potential instruction begins with a "V" and branch back if no valid instruction is found. All the new code is in several new source files to avoid creating problems in the existing code. What remains then is to copy some code for storing the instruction into the correct location, and to figure out expression parsing to support the assembler syntax / notation discussed in the ROOL forums recently.
Unfortunately life is taking over for a while and it's going to slow down development. It make take a little more time than expected get this one finished but it remains the highest priority task we are working on.
Thursday, 23 June 2011
Tuesday, 14 June 2011
BASIC frustration
Another week has gone and this one has been quite frustrating. While some assistance from the ROOL forum's sorted out some bugs in the assembler (and I even found one in !DecAOF so it's not all my fault!), work on the BASIC source hasn't really progressed.
The BASIC source code is like a bowl of noodles - it's all tangled up and it's hard to see where something stops and something else starts. It reminds me of a BASIC program full of GOTO statements where you can't follow the flow, but in assembler it's worse as there is stack and flag management plus register preservation to consider. Reading this code is not only draining my enthusiasm it's also making me think seriously about a re-write. When you only have a few hours a day to work on something you don't need to waste most of that time trying to figure out what a bunch of crazy branch and magic numbers operations are trying to do. The memory management isn't suitable for what we need in TAG either, and it's missing key data-types as previously posted.
We've already internally had an informal correspondence about a JIT compiler written in a a higher level language instead of an interpreter written in assembler. I'm mulling over the consequences of all this at the moment while trying not to get any more stressed about the whole thing. Time for a deep breath...
The BASIC source code is like a bowl of noodles - it's all tangled up and it's hard to see where something stops and something else starts. It reminds me of a BASIC program full of GOTO statements where you can't follow the flow, but in assembler it's worse as there is stack and flag management plus register preservation to consider. Reading this code is not only draining my enthusiasm it's also making me think seriously about a re-write. When you only have a few hours a day to work on something you don't need to waste most of that time trying to figure out what a bunch of crazy branch and magic numbers operations are trying to do. The memory management isn't suitable for what we need in TAG either, and it's missing key data-types as previously posted.
We've already internally had an informal correspondence about a JIT compiler written in a a higher level language instead of an interpreter written in assembler. I'm mulling over the consequences of all this at the moment while trying not to get any more stressed about the whole thing. Time for a deep breath...
Sunday, 5 June 2011
Handlers and BBC BASIC
As I work through creating a test script for all these VFP and SIMD instructions, my mind is wandering a bit to one of the next challenges for TAG. TAG uses what we call Handlers to develop code for an application. The handlers respond to events thrown by TAG for all the useful things you might need in a game. These go from starting up and closing down, to rendering, and collisions. The events are comprehensive enough to deal with all the major things a game such as BHP requires.
Handlers are developed in assembler through a support library linked into the BASIC assembler. They are saved as a simple binary file with two entry points at the start, similar to a RISC OS module, one for frame events, and one for IRQ events. For us technical developers this is great, but for most people this is beyond their capabilities.
We considered writing a C interface, but ultimately for the average-Joe this isn't really much easier than writing in ARM assembler. You also need a whole load of compilers and stuff to get started and the Acorn PRM documentation is all aimed at assembly programming.
Acorn computers were always the easiest to use and to program. BBC BASIC was famous for it's no fuss approach to programming, and for being interpreted - making it much easier to understand what was going on. However over the years the language has become outdated. It lacks object orientation and Unicode, plus it can not be used outside of an "application" to create Modules or class libraries, nor can it easily be used within another application such as TAG.
Visual BASIC .NET has become the ultimate version of BASIC available today as it is a complete language. You can do everything that you can do in C/ C++/C# with a much more friendly syntax. My development teams of nearly 20 people created vast web applications, data-processing systems, and real-time shop floor manufacturing systems with it. Recently a customer who is into mathematics was dabbling in some programming, and no prizes for guessing he was using VB to write some code. I asked him about C/C++ and he said it was far to much hassle for what he wanted to do and BASIC was much simpler to use.
Sticking to the Acorn roots I'm contemplating a new version of BBC BASIC. Simple, interpreted, and as easy to use as always, but modern and powerful in it's capabilities. Backwards compatible with existing code, but forward thinking as it can be used to develop anything. Pulling the best bits of VB.NET as a language and syntax it would allow a framework for creating a class library that interfaces with RISC OS, Toolbox, and all the other things required for building applications rapidly.
A debugger is essential and the interpreter could be written with one in mind. An interpreter makes it possible to change the code in-line whilst debugging rather than having to have vastly complex compiler technology.
Perhaps it's biting off too much, I'm not sure. All I know is that it's taken a week part time to write an assembler from scratch using BBC BASIC and I'm back in love with the language that started off computing for me in 1984 on the BBC B. It would be great for RISC OS to maintain the Acorn tradition of being the easiest to use and program operating system bar none.
Handlers are developed in assembler through a support library linked into the BASIC assembler. They are saved as a simple binary file with two entry points at the start, similar to a RISC OS module, one for frame events, and one for IRQ events. For us technical developers this is great, but for most people this is beyond their capabilities.
We considered writing a C interface, but ultimately for the average-Joe this isn't really much easier than writing in ARM assembler. You also need a whole load of compilers and stuff to get started and the Acorn PRM documentation is all aimed at assembly programming.
Acorn computers were always the easiest to use and to program. BBC BASIC was famous for it's no fuss approach to programming, and for being interpreted - making it much easier to understand what was going on. However over the years the language has become outdated. It lacks object orientation and Unicode, plus it can not be used outside of an "application" to create Modules or class libraries, nor can it easily be used within another application such as TAG.
Visual BASIC .NET has become the ultimate version of BASIC available today as it is a complete language. You can do everything that you can do in C/ C++/C# with a much more friendly syntax. My development teams of nearly 20 people created vast web applications, data-processing systems, and real-time shop floor manufacturing systems with it. Recently a customer who is into mathematics was dabbling in some programming, and no prizes for guessing he was using VB to write some code. I asked him about C/C++ and he said it was far to much hassle for what he wanted to do and BASIC was much simpler to use.
Sticking to the Acorn roots I'm contemplating a new version of BBC BASIC. Simple, interpreted, and as easy to use as always, but modern and powerful in it's capabilities. Backwards compatible with existing code, but forward thinking as it can be used to develop anything. Pulling the best bits of VB.NET as a language and syntax it would allow a framework for creating a class library that interfaces with RISC OS, Toolbox, and all the other things required for building applications rapidly.
A debugger is essential and the interpreter could be written with one in mind. An interpreter makes it possible to change the code in-line whilst debugging rather than having to have vastly complex compiler technology.
Perhaps it's biting off too much, I'm not sure. All I know is that it's taken a week part time to write an assembler from scratch using BBC BASIC and I'm back in love with the language that started off computing for me in 1984 on the BBC B. It would be great for RISC OS to maintain the Acorn tradition of being the easiest to use and program operating system bar none.
Friday, 3 June 2011
VFPv3/SIMD Assembler Progressing
The last couple of days have been spent full-time on the VFPv3 / SIMD assembler for BASIC. It's now approaching a first complete version as I've been through a lot of tidying up and commenting. Some SIMD instructions remain to add as it's a very large instruction set but all the major ones are there now.
The exercise in writing an assembler has been fantastic in getting an understanding of the instructions and their uses. I've had to read through the variations of each instruction and the associated encoding formats. The only headache has been errors and inconsistencies in the ARM reference manual. I guess with everyone using C compilers these days few people delve into raw machine code.
The reason for all this work on VFP is to create a new 3D calculations library for TAG. This has to run using hardware floating point to achieve the performance and accuracy we require. We've decided not to go with Mesa Open GL now as it won't run fast enough and will take significant effort to get running. However we will revisit it in future if time permits. An open source driver for the PowerVR/SGX hardware may well end up in the Mesa code-base.
Today I also downloaded the RISC OS source and took a look at the BASIC source code. The idea is to add the VFP and SIMD instructions to the BASIC assembler while learning about how it works to add language extensions. Sadly the code appears poorly structured and documented. Thankfully it isn't that large so it should be possible to digest what is going on. I'll try and get my head around it after I've completed the VFP library.
The exercise in writing an assembler has been fantastic in getting an understanding of the instructions and their uses. I've had to read through the variations of each instruction and the associated encoding formats. The only headache has been errors and inconsistencies in the ARM reference manual. I guess with everyone using C compilers these days few people delve into raw machine code.
The reason for all this work on VFP is to create a new 3D calculations library for TAG. This has to run using hardware floating point to achieve the performance and accuracy we require. We've decided not to go with Mesa Open GL now as it won't run fast enough and will take significant effort to get running. However we will revisit it in future if time permits. An open source driver for the PowerVR/SGX hardware may well end up in the Mesa code-base.
Today I also downloaded the RISC OS source and took a look at the BASIC source code. The idea is to add the VFP and SIMD instructions to the BASIC assembler while learning about how it works to add language extensions. Sadly the code appears poorly structured and documented. Thankfully it isn't that large so it should be possible to digest what is going on. I'll try and get my head around it after I've completed the VFP library.
Subscribe to:
Posts (Atom)