What is the base for deciding whether a language is "assembly language" or not??

Started by hackerlabs, July 19, 2010, 11:34:28 AM

Previous topic - Next topic

hackerlabs

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!

hutch--

Simple, assembler programming manipulates instructions hard wired into the processor, the rest manipulate larger blocks of code and tend to get slower for it.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

hackerlabs

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?

hackerlabs

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?

jj2007

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.

hackerlabs

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!

hackerlabs

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#.

gwapo

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  ::)

hackerlabs


hackerlabs

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..

Rockoon

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.

When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

hackerlabs

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.

dedndave

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

hackerlabs


dedndave