This page will include the following, as I get around to them ; Contents.
(a) Introduction.
(b) Unique features.
(c) Implementation so far.
(d) Possible implementation methods.
(e) Format.
(g) How it works.
(h) What it does.
(i) What it can do.

(a) Introduction.
The assembly language of OOAS (Object Oriented Assembler System - just thought of it) is basically (dah) object oriented - that is it uses features of object oriented languages, such as encapsulation and polymorphism, and instantiation of data, mixed in with lower level assembly language constructs.

What this means is that program control and transfer of control (say, for example, CALLs and RETs, as well, to a limited extent, jumps) are taken over by the assembler, and correctly determind at run time, as the program/object compiles. There are several possible syntax of the assembler (syntax is unimportant - it is defined simply in the VMS and different methods may be used) and I will probably allow all of them, to give the programmer the choice to use what they are comfortable with, however for example here, I will use something similar to a pascal like syntax ;

multiply=object
data1,data2,result:integer;
method do(d1,d2);
begin
mov ax, d1
mov data1, ax
mov bx, d2
mov data2, bx
mul bx
mov result, ax
end;
This shows a simple object which multiplies two numbers together, and stores both the multipliers, and the result in itself, for future reference.

This is essentially simple, however when we apply the snippets method of coding to this, we get the following ;

multiply=object
data1,data2,result:integer;
method do(d1,d2);
begin
mov ax, d1
{BEGIN:STORE1}
mov data1, ax
{END:STORE1}
mov bx, d2
{BEGIN:STORE2}
mov data2, bx
{END:STORE2}
mul bx
mov result, ax
end;

We have now got two snippets of code, which simply store the data values 1 and 2. We can now make a child method, which uses the same code (no new code at all, in fact), but which doesn't store the result, simply by Excluding the storage code;

multiply_no_store=object(multiply)
method do(d1, d2:integer);
{EXCLUDE:STORE1}
{EXCLUDE:STORE2}
end;

There - now since the method do had no code attached to it, the previous code of method do was inherited, however the two EXCLUDE commands after the do method tell the assembler to remove the storage parts of the code before compiling.

Although this is a simple case, it shows how code can be reused in snippets, however it doesn't quite get across the full flexibility of the methods I'm aiming for. Code insertion is also entirely possible, in a similar way, however the main problem with this stuff so far, is that no information about the underlying structure of the methods you are replacing is recorded. Thus, when the method gets updated, your program which reuses the base code may break. In most case, however, the snippets should be pieces of the code which stay stable, and the functionality/structure should also stay the same, or similar enough to be worth re-useing.

I'm working on a better solution to this problem, where more of the code's structure is recorded, and not simply blocks of code. This should give the programmer the ability to alter the structure of the code, as well.

(b) Unique features.
The most unique feature of this language is that it belongs to no particular microprocessor. The "operating system" forms a virtual layer between the assembly language code, and the machine that language is for. The Key to the whole thing is the VMS. The VMS makes the entire operating system portable at its most basic level, while still allowing direct machine programming (apparently, from the programmer's point of view).
This also allows us to experiment with what I call "programming by method" rather then programming by code. This means we tell the OS or rather the assembler the method to do what we want our program to do, specifically, rather then giving it code to perform this task. We look at the code we write as a description of how to do a task to the OS rather then as actual code to be performed by the microprocessor. This makes our "code" very portable , as the method will work on any microprocessor, while normal code will only work on the processor (and quite often the machine) it was programmed for.
It also allows our code to be very flexible as well, giving us the opportunity to program with an extended assembler set, of what would normally be macros, and to compress and store our programs any way we wish.