Hey everyone!
Right...so this is more of an ideological one :P
I like assembly programming.
But when I tell people that I can program in Microsoft Intermediate Language(it's the assembly language every .NET language is compiled to), they turn around and tell me, "Oh, but that isn't assembly!".
I can't see why!
I mean, think of the .NET Framework as a virtual machine. An abstract machine.
(Hell, that's what it is!)
MSIL is the closest you can get to the VM, right?
Same goes for the JVM - Java bytecode is the closest you can get to the Java VM.
So even if these languages support object-oriented extensions - why can't they be classified as assembly languages?
Assembly language is all about harnessing the power of your architecture..getting the most out of your machine.
MSIL and Java bytecode do the same - if I write code in MSIL or Java bytecode, I can actually do stuff which is either too complicated, or isn't possible with C#, or Java.
Your ideas and views, s'il vous plait!
Simple, assembler programming manipulates instructions hard wired into the processor, the rest manipulate larger blocks of code and tend to get slower for it.
Quote from: hutch-- on July 19, 2010, 11:59:45 AM
Simple, assembler programming manipulates instructions hard wired into the processor, the rest manipulate larger blocks of code and tend to get slower for it.
Okay.
Point.
But then - using MSIL, as opposed to using C#, yields increased speed.
Just the way using assembly in place of C does.
Does that qualify?
For a minute, think, *imagine* the .NET stack as a VM.
The MSIL I write, manipulates instructions hardwired in the VM.
Which, in turn, allows me to, for instance, write faster code.
Use pointers - although that's possible with C# as well.
So, in such a scenario, wouldn't MSIL be counted as assembly?
MSIL will eventually be translated into machine code, i.e. to bytes that force the processor to do precisely mov eax, 123 and not mov eax, 124.
Assembler translates directly to machine code...
We could say "assembler is what can be used by ml.exe, jwasm.exe, tasm.exe and other known assemblers" - that would be a convention but it is no solution to your valid question.
Quote from: jj2007 on July 19, 2010, 01:07:21 PM
MSIL will eventually be translated into machine code, i.e. to bytes that force the processor to do precisely mov eax, 123 and not mov eax, 124.
Assembler translates directly to machine code...
We could say "assembler is what can be used by ml.exe, jwasm.exe, tasm.exe and other known assemblers" - that would be a convention but it is no solution to your valid question.
Yeah...well.
I guess I should simply be happy with the fact that I can write code in MASM, as well as MSIL :P
Thanks, guys!
Lately, I've been experimenting with linking code written in different assemblers.
Like, I write a DLL using MASM, and use it in a program written in MSIL.
Stuff like that.
Gives me the best of both worlds: unmanaged and managed, without the limitations of C or C#.
They have their own respective names: Intermediate Language for Microsoft .NET and ByteCode for Oracle Java.
From the book I've read, the author described Assembly Language as a low-level language for programming microcontrollers, microprocessors, and integrated circuits.
But of course, there are also many high-level things we can code using assembly language ::)
Yeah.
Look at MASM - freakin' awesome!
Even HLA.
Gotta admit it - MASM is one hell of a language to work with.
Things just couldn't get better.
HLA is good too - Randy really made life interesting..
MSIL is an assembly language, but is not the native assembly language of the processor you are using.
Its an assembly language for a fictional machine that doesnt exist, in much the same way that C programmers target an abstract machine that doesn't exist. Abstractions have their uses.
C is the assembly language for the C abstract machine.
MSIL is the assembly language for the .NET VM.
Java's bytecode is the assembly language of the JVM.
In the case of Java's byte code, there are actually machines which execute it natively (but yours isnt one of them):
http://en.wikipedia.org/wiki/Java_processor
The difference between Intel/MASM/GAS/etc syntax assembler as is, is that in these cases, its for a REAL machine.. the one in front of you.
That's one way of putting it!
As for the Java processor - it's pretty interesting.
I tried to buy it once, but then - funding is always an issue!
But the idea of executing Java bytecode directly on top of bare metal is cool.
Wonder how fast it would be.
Also, it'd be fun - implementing MSIL on top of bare metal.
to be precise, calling an API function isn't assembly language, either :P
but, at least in my code (lol), most of the stuff between API calls is
using macros is a step toward higher level language, too
if you are using mnemonics based on the CPU manufacturers processor, that is assembly language
Yep. Another point.
Hey Dave!
What's up?
:D
the sky :bg
do i know you from somewhere ?
Rudi,
The distinction is between abstract systems and hardware, each hardware type has its native language which is usually referred to as an assembler but when you use the term for an abstract system you are using it differently to hardware related instruction sets. The plus for abstract systems is it is portable in at least some instances where the assembler for one form of hardware will not work on another, x86 v PPC v Motorola 68k v Z80 etc ....
Um...not really, no.
But remember the post in the HLA forum?
About writing a kernel in HLA?
You'd posted a reply - so in my dictionary, we're acquainted :P
Quote from: hutch-- on July 19, 2010, 01:50:07 PM
Rudi,
The distinction is between abstract systems and hardware, each hardware type has its native language which is usually referred to as an assembler but when you use the term for an abstract system you are using it differently to hardware related instruction sets. The plus for abstract systems is it is portable in at least some instances where the assembler for one form of hardware will not work on another, x86 v PPC v Motorola 68k v Z80 etc ....
Ah.
Now that clears the mist up :P
Yeah. Thanks, Hutch!