ANY Platform

News

Things are going to be rather rudimentary at this domain for a little while as I start designing the ANY platform. Documents will become available as I progress. The very first actual "code" that will appear under ANY will be to design file I/O, data types and command-line I/O. Sure, command-line isn't particularly pretty, but it's a start, which is what is necessary right now.

September 29th, 2007

I am definitely not dead. More like, incredibly busy working on the latest and greatest for Any.

The AnyScript language is being worked on and many design decisions changed to make it a superior language to use. For the time being, the final version is in flux so any AnyScript samples may, in the future, be null and void (or maybe null and Nothing? =)~)

After carefully deciding, several small changes are being made to the way Any handles signed versus unsigned values, as well as a few minor design changes.

In cases where sign extending was ignored even if the value was signed, such as bitwise operations, they will now sign extend.
ShiftArithmeticRight has been removed and ShiftRight will use logical right shifting if the destination is unsigned and arithmetic right shifting if the destination is signed.
Comparison type statements, such as Compare and Test are now required to have conditional statements afterwards, such as JumpCondition and SetBoolean. Aside from truly connecting the two as many processors, such as the Super-H, do internally, this allows the number of condition types to drop since the condition statements now will rely on the unsigned/signed data type of the comparison to make decisions based on that.
For example,
Compare somevalue, 1; JumpIf Greater, SomeLabel;
This will use an unsigned greater (aka above) comparison if somevalue is unsigned, and a signed greater if somevalue is signed.
The ReturnSubCondition instruction has been removed since it's uses are very limited and next to no processors support it natively (the Super-H is the only series that comes to mind).
The LoadEffectiveAddress instruction has been removed as a user instruction and is now only available as a backend instruction. The ability to load an address into a non-pointer has been removed as it creates all sorts of problems when handling data in a system-independent manner. Pointers are not reliably in any format on any system.
ByteSwap was renamed to SwitchEndian since that is a more descriptive of it's operation.

And lastly, the Any Platform C++ library is being built, which makes it so that C++ can use the same library calls as Any itself will use. This is coming along fairly well and a compilable version will be released soon. Since pseudo-classes don't actually exist in C++, an Any name space is being used instead. It will be available under the LGPL license and most of the initial versions of the full Any Platform will be written using it.

June 17th, 2007

I have finished many revisions on just about every single encoding script. All that is left to do for the 32bit x86 encoding scripts is creating Size/Speed versions where not available. For testing purposes, I will just use the size versions if available, then the speed versions. You can download the latest versions of all of the encoding scripts below. Now I can finally start on the real coding!

June 11th, 2007

This last month has been filled with a lot of revisions, planning, and getting stuck a lot. I have reached a point where several issues exist that can "make or break" the best functionality available. Since these issues are rather lengthy to discuss, I have added a "Programmatic Issues" section below. In any case, the only instructions left now are: LoadAddress, Compare, TestCompare, Divide, DivideModulus, Modulus, Multiply. I am not planning on having Divide and Multiply operations ready ahead of time since I really want to get the assembler rolling. Also, I'm debating removing LoadAddress as a separate instruction and instead reclassifying it as an internal operation. I will upload the latest XML files in the next couple of days, just as soon as I complete Compare which I believe is the last operation that is really necessary before some sample programs may be written.

Lastly, someone else has actually shown interest in Any in the last week, which is a first for me. Peter Fedorow, who is creating his own programming language called QuickForward, has been giving me ideas on how to proceed with AnyScript, the high level language for Any which has yet to be completed.

May 4th, 2007

I have about half of the mnemonics prepared now for 32bit x86: Add, AndNot, ByteSwap, Complement, Decrement, Exchange, ExclusiveOr, InclusiveOr, Jump, JumpCondition, JumpSubroutine, Move, Negative, NoOperation, SetBoolean, ReturnSubroutine. These are optimized for Pentium and Pentium MMX processors, so they are not optimally coded for P2+. Right now, however, functionality is more important than optimization. Also, I have decided not to support -1/0 boolean and instead use only 1/0 boolean for the x86. For all operations except Move, 1/0 is faster.

The following mnemonics have been added to the list of AnyASM mnemonics: ByteSwap, GetReturnValue, ReturnSubCondition. ByteSwap switches a value's endianness. GetReturnValue is an alternate way to store a returned value from a function or mnemonic and I feel it will be necessary for some more complex mnemonic support, such as MultiplyUp. ReturnSubCondition only works from Subroutines (like GOSUBs in BASIC), which I feel are an incredibly powerful and under-used feature of programming.

There are many other mnemonics in the Mnemonics file below that I am debating adding native support for. A lot of these may end up just being inline functions, but having them as native mnemonics means they will be more optimal and that you can rely on their existence on every platform.

April 2nd, 2007

While trying to code this compiler, all I have to say is, "Wow!" What an enormous amount of work it is. It was complicated just creating a solid XML file format for converting from AnyASM mnemonics to 32bit x86 mnemonics. I have that format pretty much nailed and have been building the conversion scripts for various instructions. The only "done" instruction is Move which is now completely done for U/S8-32bit values as well as Booleans. However, Xor, Or, And, AndNot, Add and Subtract should all come soon and then most Unary types. I was hoping to have something functional at this point, but real-life is keeping me from getting as much done as I would like to.

February 15th, 2007

I've worked out the rudimentary portions of the AnyASM language. Now I just need to flesh out the base objects, figure out how to get DLLs working in Windows and write the simple compiler. One fortunate thing about the DLL model and Any is that I won't have to deal with DLL-hell. If a user updates Any to the latest version, it will know when the DLLs that it comes with have changed enough to warrant a recompile and thus keep all the user's Any software up to date. Personally, I think that's really cool.

Files:

Information and Language Documentation

Description/Definition of the goals of the ANY Platform
This includes a source-level example of a simple program that assembles to 16bit x86, 32bit x86 and 68K assembly.

AnyScript Data Types
This currently incomplete data sheet shows the preliminary list of data types that AnyScript and AnyASM will support. Note that AnyScript is a very strongly typed language but has variant data type support. One key thing that AnyScript and AnyASM do that no other language I know of does, is native support for extended bit-sized data, such as 128bit and 256bit data types, as well as supporting "special" but still sometimes used data types such as 24bit or 48bit values. When floating point operations are added, an "unbounded" floating point data type will be supported as well, giving limitless number processing capabilities (albeit slow).

AnyASM Mnemonics
This is a list of the mnemonics supported by AnyASM. Higher level functions will be supported with pseudo-objects, such as Block.Move and Math.Sin. Also contained is a rudimentary description of the format of AnyASM files.

AnyASM Objects
This is a very VERY rudimentary list of the supported AnyASM objects. This bare-minimum is enough to get the system started and further functionality will definitely be added later. Since the initial version of AnyASM will be v0.0.1, things will definitely become more functional as time progresses. Many of the objects here will be "pseudo-objects", meaning they are accessed as if they were objects but the final assembler on various systems may make various methods or functionality inline. For example, the Block object should be mostly inline when completed. A Block.Set() operation might become a rep stosd with the appropriate settings on an x86, for example.

Code Samples

All of the AnyScript and AnyASM samples are in text files so your browser (and text editor) will display them properly. Note that the AnyASM samples are the pseudo-assembled versions of the AnyScript files. The AnyScript language is not yet complete and therefore the final versions will look different than these samples! These were hand-converted, but this is how things should look from an assembler.

Hello World (AnyScript - AnyASM)
This is the really simple, basic "Hello World" application as it would appear in both AnyScript and in AnyASM. The AnyScript version is only three lines of code. No include files! No header files!

Command Line (AnyScript - AnyASM - 32bit x86 Assembly)
This sample shows how the command line will work. Essentially it's the same as C/C++, but with much more meaningful names and using the way more useful String data type (vs null-terminated).

Display Text File (AnyScript - AnyASM)
This example looks for a "Test.txt", opens it if it exists and outputs it to the screen. The AnyASM for this example is rather complicated.

AnyASM Mnemonic to x86 XML Scripts

All of the following are optimized/timed for the Pentium and Pentium MMX, since these are processors I am accustomed to programming for. I started writing the scripts optimized for speed, but opted to start writing new scripts optimized for size, hence why some have one or the other. Size will be better suited to any processor, whereas speed would be best only for P1 and P1MMX. The final initial set will have all mnemonics optimized for size. Also, various functions in the XML will call functions that exist in a separate assembly file, which is available here. Over half a meg of code so far! Oy!

NOTE: I use 2 spaces per tab, so some of the following may not line up properly if you use a different tab size.

Mnemonic Encoding Rules (incomplete)
Mnemonic Functions
Add (Size)
And (Size)
AndNot (Speed)
Call - Just the code to do the call
Compare (Size)
Complement (Size)
Complement (Speed)
Decrement (Size)
Exchange (Speed)
ExclusiveOr (Speed)
GetReturnValue (Size)
InclusiveOr (Speed)
Jump
JumpCondition (Size)
JumpCondition (Speed)
JumpSubroutine
Move (Speed)
Negative (Speed)
NoOperation
Return (Size) - Just the code to set the return value
RotateLeft (Size)
RotateRight (Size)
SetBoolean
ShiftLeft (Size)
ShiftRight (Size)
Subtract (Size)
SwitchEndian (Size)
Test (Size)

Programmatic Issues:

Below are listed several programmatic issues which I am not exactly certain of the best way to resolve them. One thing that Any does that no other language I know of does, is that it permits Booleans to be treated as numbers for several purposes. For example, if you add a Boolean to an Int, it will add 1 if the Boolean is true, and 0 if it is false. However, there are times when I get stuck on this, because what should happen if you add an Int to a Boolean? Should it add the full Int, then keep only the low bit, as if the Boolean was a 1bit value? Or should it convert the Int to a boolean value first, then add the two 1bit values together and store the low bit?

Under each issue is a list of the ways I think it may work. The description of the handling method is bolded, followed by a functional analysis. If anybody has any ideas how best to handle some of these issues, I'm open to suggestions. Yellow items are the way it is currently being coded.

Comparing with Booleans
When comparing non-booleans and booleans, there are three ways we can handle the comparison, listed below.
1. Treat the booleans as a numeric value of 0 or 1
  In most other mnemonics, a boolean has a numeric value of 0 or 1 (see Add for example). This would keep this behavior consistent. However, using a boolean as a "true" or a "false" would make it seem strange if
  Compare 2, True;
  came out to "Not Equal"
2. Always convert the non-boolean to boolean
  Equality would test only if both values were non-zero (true) or both were zero (false). Greater/Above would test if the left value was non-zero and the right value was zero. Less/Below would test if the left value was zero and the right value was non-zero.
3. If the boolean is the L-value, then convert the non-boolean to a boolean. Otherwise, treat the boolean as numeric value of 0 or 1
  This is a "best of both worlds" version, but probably the most confusing for programming purposes. Let's look at two vars:
  ProcInt q; Boolean b;
  If we used:
  If (q == b)
  then the condition would only be true if q was 1 and b was true, or q was zero and b was false, just like #1 above. Greater and less comparisons would also work the same as #1. However, if we used:
  If (b == q)
  then the condition would be true if q was non-zero and b was true, or q was zero and b was false.
  This and the greater and less comparisons would work the same as #2.
I personally am in favor of #2 or #3 above, but I can see reasons why #1 might also be useful.
Bitwise Operations with Boolean
Bitwise operations (And, AndNot, Eor, IOr, Neg, Not) may be handled a few different ways: (note that Neg and Not work the same regardless)
1. Treat the boolean as if it was a numeric value of 0 or 1
  And, AndNot, Eor and Ior would only affect the boolean value based on the low bit.
2. Always convert the non-boolean to boolean
  Regardless of where the boolean was, the non-boolean would be converted to a boolean.
3. If the boolean is the L-value, then convert the non-boolean to a boolean. Otherwise, treat the boolean as numeric value of 0 or 1
  And, AndNot, Eor and Ior would affect an L-value boolean the same as if a boolean operation occurred. If the R-value was non-zero, then a 1 would be used. If it was zero, then a 0 would be used. Operations where the boolean was an R-value would treat the boolean as if it was a 0 or a 1
I personally am in favor of #2 or #3 above, but I can see reasons why #1 might be useful. A huge plus for using #2 is that the same code may be used for the bitwise operations and for boolean bitwise operations (in C/C++: && and || for example).
How should we extend on bitwise operations?
When using a bitwise operation between two values (And, AndNot, Eor, Ior), how should we extend values?
1. Always zero extend
  If we do things this way, bitwise operations always occur only on the exact bits of the value in question. However, this makes is impossible to use the sign-extend method without type casting smaller values to larger ones first.
2. Sign extend for signed values
  If the value is signed, sign extend it before performing the operation. If you want the "zero extend" behavior you can always direct cast the value to unsigned.
Since #2 gives the greatest flexibility, it will be used for bitwise operations.
More boolean arithmetic
Because of the "free" attitude of boolean, we have a few strange interpretations of how boolean values interact with other values. For the following instructions, boolean values are treated as a 1bit value and act just like other numeric types: Add, Complement, Decrement, Divide, DivideModulus, Increment, Modulus, Multiply, Negative, RotateLeft, RotateRight, ShiftArithmeticRight, ShiftLeft, ShiftRight, Subtract
For the most part, this generally means the arithmetic (if any) occurs and only the low bit is kept. Each of the examples below assumes we have a boolean b and a ProcInt a. In a few cases, this causes some unusual or unexpected results when the boolean is the L-value:
- In Add and Subtract, the value is in essence XOR'd with the low bit of the modifier. For example (in AnyASM):
  Add b, a;
  b will seem to be affected as if we did (in AnyScript):
  b ^= a & 1;
- In Decrement, Complement and Increment, the value is flipped (as expected with Complement).
- In ShiftLeft and ShiftRight, the value becomes 0 if the modifier is non-zero, otherwise it is untouched.
- In RotateLeft, RotateRight and Negative, the boolean value never changes. In fact, no code will be generated either.
  Negative might be placed with Complement, except that it adds 1 after flipping the bit, which is the same as doing a Complement followed by an Increment, which would cause the value to be flipped twice.
- In Divide and DivideModulus, the value becomes 0 if the divisor is greater than 1, otherwise it is untouched.
- In Modulus, the value becomes 0 if the divisor is 1, otherwise it is untouched.
- In Multiply, the value becomes 0 if the modifier's low bit is not set, otherwise it is untouched.

Simple FAQs

To be dizzyingly precise, only one person has asked me anything yet, so I guess these aren't truly "frequently" asked questions. Still, I figured that adding some Q&A would be helpful.

Why did you start this project?

I have always been a computer junkie since my parents bought an Atari 800XL back in about 1983 (I was 4 or 5). After moving out on my own, I was able to relive my younger years through what are called "emulators", programs that read data files with the instructions meant for other computers (like that Atari 800XL) and bring them to life on modern computers. I even have an enormous amount of work done on my own emulator because I wanted to consolodate the best features of them in a single program (and no, it's not available, it's not ready for release yet).

It was while researching some really cool processors that never got much attention that I started thinking about what eventually became the ANY Platform. In particular, I was reflecting on why we are still bound to the x86 processor platform (for those of us using Windows, anyways), when so many far superior processor architectures have been created since the 8086 was first introduced back forever ago. To explain this fully would require a crash course in assembly language and processor features. What it all boils down to is backwards-compatability; every program ever written for the 8086 and above needs to be able to run on modern computers. If Intel or AMD released a new processor that removed backwards-compatability (such as Intel's Itanium), EVERY SINGLE PROGRAM would need to be at the very least recompiled and quite often heavily rewritten. To make matters worse, the same can happen when a program needs to be able to change operating systems, such as Windows XP to Linux, or even Windows 95 to Windows XP (apparently even Windows XP to Windows Vista is a pain).

This is where ANY falls into place. By completely abstracting the processor, hardware and operating system, we can instead focus on the important part: programming! If ANY ever truly gets off the ground, it can cause a breakthrough for modern computing because instead of everybody having to rely on existing processors, operating systems and hardware to support old, outdated methods of operation, we could instead concentrate on creating new methods of operation, new processors with far better instruction sets (ever take a look at the SuperH RISC processors from Renesas as an example... they seem dated now, but they could have been the next big thing!) and new operating systems could "clean up" the mess of backwards-compatability without losing support for all previous software. On a side note, if there really are aliens out there, wouldn't it be cool if we could port our code over to their systems as well? =)~

The key to this all would be dedicated programmers who would create interfaces to these new technologies for the ANY Platform, and the .Any files that would be portable to those new systems. I believe in this project because it has the potential to revolutionize programming.

What platforms are currently being targetted by Any?

On 32bit x86 systems, MS-DOS, Win32 (Win 3.1 and above) and Linux/POSIX/Unix operating systems are currently being targetted. On M68K systems, currently only TOS on the Atari ST is being targetted, though the EASy68K 68000 simulator is also being coded for since it makes programming in M68K assembly far easier when you have a powerful debugger to use. Since these are the systems I know best (MS-DOS in particular), they make the most sense for me to target first.

What are some advantages of Any compared to Java or .NET?

AnyASM is being designed to be as flexible as possible so that any programming language may be ported to it! This means that, if you wrote some really great programs back in the 16bit MS-DOS days (I have a lot myself), you can use an AnyASM assembler to convert from your language to AnyASM, and then your program can be run on modern computers. Of course these language converters need to be written, and that is something I definitely need help on to make it available to as many people and languages as possible. To some extent, even assembly language programs may be translated to AnyASM, though that'd require a bit of trickery. Anybody up for a .NET or Java to AnyASM converter? =)~
From the beginning and forever, Any is designed to be free for everybody. This is the biggest reason I am using the Gnu Public License as opposed to a BSD license: it forces anybody using the code to also use it only for free software. The intention is to prevent some other company coming by and re-licensing the idea and code under their name and label, then marketting it. Of course this doesn't apply to code COMPILED with Any. I feel that, should software companies decide to write software in Any (or convert to Any) that they should be able to sell their software just like it was written in any other programming language.

What is a .Any file? How does it work?

A .Any file will be an archive of the AnyASM files and any settings that need to be passed along to the compiler. The goal is to make everything required for a successful compile to be merged into a single file. This will allow the same file to be able to be compiled on any system that meets the program's minimum requirements. Any user-controlled settings will be configured in the ANY Platform interface on the user's system and will be independent of the .Any files for final products. The .Any file format has not currently been created.

What's the difference between AnyScript and AnyASM?

AnyScript is the high-level programming language equivalent of AnyASM. AnyASM is the system-independent psuedo-assembly language used by the ANY Platform. The difference between the two is that AnyScript supports fully compounded, high-level programming ideas and constructs (it's somewhat like C++), whereas AnyASM is designed to break everything down to a rudimentary level and looks similar to assembly languages for specific processors.

AnyScript Example:
p = ((++q) < x) ? y : ((z * 21) + n);

AnyASM Equivalent:
Inc q; Compare q, x; JumpIf GreaterOrEqual, TempLabel0; Move p, y; Jump TempLabel1; TempLabel0: Move p, z; Multiply p, 21; Add p, n; TempLabel1:

Why is it taking so long?

Currently, I have nobody helping me on this project. I have to design a pseudo-assembly programming language from the ground up which (hopefully) supports natively the best features of most processors, supports all features from pretty much all high level programming languages, can be extended for further support, create sample programs, and make a compiler. This is a daunting task, to say the least, and occupies enormous amounts of my spare time.

Why are some of the available documents incomplete?

I am uploading files as I make them, often before I finish.

The ANY Platform