http://www.viksoe.dk/code/index.htm
Lately we have been swamped with Bill Gate's new .NET vision. Once again even respectable people are crying out that C++ and assembler programmers will become extinct dinosaurs. My reaction to that is: "It's not fair!" Why are they always picking on assembler programmers? We don't do a lot of harm! Just because we like to have total freedom and like to be close to our hardware doesn't make us bad people. Go pick on someone else (like LISP programmers. I don't like them).
Frankly, I was getting a little tired of this whole discussion, so I decided to do something about it - by bringing x86 assembler programming into the .NET age. Well, at least to allow ASP.NET pages to be written in 80386 assembler.
To do just that, I've written a compiler (assembler?) that compiles 80386 assembler code into MSIL. In other words, you get to write assembler programs that compiles into the same IL of the .NET's Common Language Runtime that your fellow VisualBasic.NET and C# developers are using. So basically you can enjoy the thrill of low-level programming and still be compatible with your "oh, so modern" VB.NET friends.
What?!
Yup, it's true. It's really the x86 (Intel 80386 actually) instruction set that gets compiled into IL. Literally it is an "80386 Assembler scripting Language" for ASP.NET.
"Very Usefull", you might think! "Just the sort of thing you have been looking for", I hear you say! Thanks, I do my best to support my kindred spirits.
You use the compiler in ASP.NET by replacing your usual VBScript.NET script code with 80386 assembler instructions. In addition you use the keyword Asm80386 as page language.
The compiler
Short-term goal
Because I didn't really want to spend too much time on this project, I set out a short-term goal: to create my first web-page in assembler.
That is, to be able to execute this ASP.NET script:
<%@ page language="Asm80386" %>
<%
Str: DB "Testing...", 0
mov eax, -2
cmp eax, 2
jle Label1
xor eax, eax
Label1:
lea esi, Str
push esi
call "Response.Write(string)"
pop esi
%>
<br>EAX: <%= eax %>
Instruction support
The following instructions are supported
NOP, MOV, LEA, CMP, TEST,
ADD, SUB, XOR, NOT, NEG,
INC, DEC, OR, AND,
IMUL, IDIV, MUL, DIV,
SAL, SHL, SAR, SHR,
CBW, CWDE, CWD, CDQ,
CLD, STD, CMC, STC, CLC,
PUSH, POP, JMP, CALL,
JE, JZ, JNE, JNZ, JS, JNS, JB,
JNAE, JAE, JNB, JBE, JNA, JA,
JNBE, JL, JNGE, JGE, JNL, JLE
JNG, JG, JNL, JC, JNC,
JCXZ, JECXZ
Limitations
Not all operand constructs are supported. Instructions, which are available in multiple forms (such as IMUL) only support 1 form. Registers AL, AX and EAX types are supported - but AH and its friends are currently not. There is no support for segments qualifiers, special 80386+ registers or any of the fancy prefix types (REP or LOCK). Since segment registers are not supported, a flat memory model is used. The addressing form [BX + SI] is not supported. The stack space is limited to 200 DWORD entries. Use $ to denote hexadecimal. ASP.NET debugging is awkward, but works. The CALL instruction can handle CLS calls using quouted strings, but ordinary sub routines are not supported (there is no RET support). Plenty more limitations may apply.
But what about...
Direct memory access?
Nothing has changed. A security exception will tell you when you're doing something wrong. You're only allowed access to your own data segment.
Pointers in .NET?
Good point. But pointers are not bad in .NET (performance is, though). Pointers are still there - they are just considered evil. With 80386 scripting you can still generate memory exceptions and bring the web-server down. It's things like this that make assembler programmers feel powerful.
Access to the hardware?
Yearh, well, you'll just have to sacrifice something to be modern in the world we live in today.
Speed?
Converting a language like 80386 assember to another low-level instruction set is, as you can imagine, not a healthy thing for code performance. In other words, the performance suck big time.
What did you expect? This is what we have been trying to tell you guys for years and years and years. Do the real thing - or you'll just have to buy a faster computer.
Framework access?
Like WinForms and stuff? Forget those. They are high-level crap anyway.
There is basic access to some of the ASP.NET object methods, but that's all.
Isn't MSIL stackbased?
Yes. And that's why this whole project will probably never become really popular amongst my fellow assembler programmers. The generated code is simply too slow!
The future
The future still belongs to assembler programmer! I'm not sure I'll ever get around to implement the entire instruction set or work out the details of how to manage classes and other .NET data-types... but, well, who cares.
Installation Requirements
Microsoft .NET Framework 1.0 SP1
Installation Guide
Edit the install.cmd file so the paths match your system. Then execute it.
Edit your machine.config file and add the following line to the <compilers> XML node.
<compiler language="asm80386" extension=".asm" type="Viksoe.ASMIL.AsmScriptCodeProvider, Viksoe.ASMIL" />
Create your aspx pages...
Download Files
