flat assembler
Message board for the users of flat assembler.

Index > Heap > Few questions on assembly language and machine dependency.

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
qwerc



Joined: 23 Mar 2013
Posts: 3
qwerc
Hello, I've a few questions related to assembly language and HLL and their dependency on processor.
First of all I know computer is a huge collection of circuits with only two understandable states - ON and OFF. So depending on the processor (or the network and combination of circuits), the machine language should be different for different processors. If this is correct, then compiler must have different ways to convert the source code (written in HLL) to machine code depending on the processor model. The same is true for assembler. It converts the assembly code to machine code, then how come code written in HLL is said to be portable and that in assembly is not?

I'm new to programming (trying to learn C actually), please forgive me if my questions seemed too stupid.
Thanks.
Post 23 Mar 2013, 07:41
View user's profile Send private message Reply with quote
malpolud



Joined: 18 Jul 2011
Posts: 344
Location: Broken hippocampus
malpolud
There aint no stupid questions.

It is true. Try to learn some assembly basics, then you will know why assembly code is less portable than HLL code.

The differences between different processor architectures (not Pentium 4 to Pentium Dual Core but for instance 68x to ARM) require different operations to be performed to achieve a similar thing, and because Assembly code is almost exactly translated to machine code you will in fact make different operations.

Examples of simple, easily explainable differences:
- one architecture has more general purpose registers than another.
- on a certain architecture some g. p. registers can not perform certain operations
- different data bus widths
etc,

Low level programming is so much fun and is not so scary as it might look like at first.
Post 23 Mar 2013, 09:20
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1408
Location: Toronto, Canada
AsmGuru62
"depending on the processor model" -- this is not the full picture of portability.
The output (or binary code) will also depend on a target OS.
Lets take the simple C example for this:
Code:
#include <stdio.h>

int main ()
{
        printf ("\nHELLO, WORLD!\n\n");
        return 0;
}
    

This code will be compiled for LINUX and Windows using different compilers.
Compiler for LINUX will produce the binary to run on LINUX and
same can be said for Windows. The portability of "C" code is in the fact that
the source code above needs no change before the compilation happens.

Now,

If we write the same program in Assembly, we will need the different
function (a library in fact) to produce the text on console. Not only that, but
we'll need the whole new environment to handle in our ASM code, so the
code will change -- it will be almost entirely new code. That is why it is
assumed that ASM code is not portable.

Also,

"converts the assembly code to machine code" -- there is not much conversion going on there.
Basically, the ASM code IS a machine code.

The interesting thing to add is that it is possible to code in ASM for two OS-es
without changing the source code. Try FreshIDE with FreshLib -- I think you
can write portable ASM code using that IDE for LINUX and Windows -- you even can
see YouTube video demonstarting this ability.
Post 23 Mar 2013, 14:35
View user's profile Send private message Send e-mail Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
ASM involves using specific instructions that may not be available on other processors such as division and FP arithmetic.

Marat Fayzullin's PC emulation resources: http://fms.komkon.org/EMUL8/
Post 23 Mar 2013, 15:49
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:21; edited 1 time in total
Post 23 Mar 2013, 16:12
View user's profile Send private message Reply with quote
Bob++



Joined: 12 Feb 2013
Posts: 92
Bob++
@HaHaAnonymous, even a java program needs a virtual machine to run,so,it's not portable too. IMHO,there is no any program portable. Truly portable you don't need to recompile or download another software to run(the JMV) that implies in the same thing to download a compiler. it's MHO.
Post 23 Mar 2013, 16:46
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:21; edited 1 time in total
Post 23 Mar 2013, 16:49
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
FASM can generate Java .class files. How to assemble JVM bytecode with FASM: http://board.flatassembler.net/topic.php?t=13961
Post 23 Mar 2013, 18:46
View user's profile Send private message Reply with quote
malpolud



Joined: 18 Jul 2011
Posts: 344
Location: Broken hippocampus
malpolud
HaHaAnonymous wrote:
HLL code is not really portable[..]
My opinion. Haha, opinion!


Your opinion is quite different from reality.

I don't know if you just write some bullshit to confuse the person who asked the question or voice your opinion not knowing how do things work. And it is not your first time.

Concerned here is the SOURCE code portability not the executable portability. Name one reason why the following C code is not 100% portable

int main(){
printf("aasaasd");
}

? It will run on every machine that has a C compiler, ARM, x86, 68k, PIC, 51 and anything else. Moreover it can be used within an operating system or baremetal as well. Haha.

_________________
There's nothing special about it,
It's either there when you're born or not.
Post 23 Mar 2013, 19:10
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:21; edited 1 time in total
Post 23 Mar 2013, 19:39
View user's profile Send private message Reply with quote
malpolud



Joined: 18 Jul 2011
Posts: 344
Location: Broken hippocampus
malpolud
Man, what are you talking about?
1. Time has nothing to do with portability.
2. This code is 100% portable:
I take the arm-none-eabi compiler, make no change to the code, compile it, link it with precompiled libraries and it works. I take the mingw compiler do the same things as above and it works as well. The SOURCE code is portable, you do not need to change it to run it on different machines or in different environments.
3. If you take your notebook from UK to Ukraine and face the problem of different power plugs. You need to change plugs or use an adapter. Does your notebook become unportable? Or maybe only if you can change plugs in certain time (perhaps the period of currents sine wave) the notebook is portable otherwise it is not? Wink

If you are not convinced, I am sorry, but I have no time to waist left. Go read some basic books in computer science.
Post 23 Mar 2013, 19:56
View user's profile Send private message Visit poster's website Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 21:21; edited 1 time in total
Post 23 Mar 2013, 20:05
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
malpolud wrote:

1. Time has nothing to do with portability.


AFAIK, it does.
Let's say you've written a program which runs on X86, and you want the program to be able to run on Sparc or ARM.

If the total time required to modify your code is less than the total time required to rewrite your code for scratch, then your code can be considered portable.
Post 24 Mar 2013, 13:11
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
HaHaAnonymous wrote:

Not 100% portable? It is not portable at all. So is 0%.


The source code is in plain ISO C. Just ISO C, no Windows API or POSIX stuffs involved. It's portable by definition.

If the C compiler you're using doesn't accept that code, then obviously your C compiler is not standard compliant.

Wink
Post 24 Mar 2013, 13:17
View user's profile Send private message Reply with quote
malpolud



Joined: 18 Jul 2011
Posts: 344
Location: Broken hippocampus
malpolud
I promised not to waste my time, but finally it is my time so I will waste it once more Wink

Anonymus Are you trolling?
HaHaAnonymous wrote:

Quote:
The SOURCE code is portable, you do not need to change it to run it on different machines or in different environments.
No, it's not. The executable will not contain the same bit sequence after this.
WOW. No shit Sherlock!
Quote:
The source code doesn't matter.
Read the question in the first post. The matter here is source code portability. PERIOD.

_________________
There's nothing special about it,
It's either there when you're born or not.
Post 24 Mar 2013, 13:28
View user's profile Send private message Visit poster's website Reply with quote
malpolud



Joined: 18 Jul 2011
Posts: 344
Location: Broken hippocampus
malpolud
TmX wrote:
If the total time required to modify your code is less than the total time required to rewrite your code for scratch, then your code can be considered portable.
What if the time to modify program from one arch takes 99% of the first writing? What if it takes 80%? Is it still portable? Then most ASM programs would be perfectly portable since once we design algorithms and understand the way the program works the rewriting will take much less than the first time, so according to you the code could be considered portable Wink

_________________
There's nothing special about it,
It's either there when you're born or not.
Post 24 Mar 2013, 13:33
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8864
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
Quote:

define:portable
Able to be easily carried or moved.


Quote:

define:easy
Achieved without great effort; presenting few difficulties.


Quote:

define:difficult
Needing much effort or skill to accomplish, deal with, or understand.


what is portable? what scale we want to use to measure easy & difficult, and what target is our audience?

we even got issue on what is easy and what is difficult, is programming in asm easy? or difficult?

now, programming is kinda wide, programming socket, programming erp system and etc,

source code, what source code? operating system? hello world? console? game? etc

too much ambiguous (now the question sound like bible)

java source code is portable, across different architecture, they just need their own kind of jvm.

could asm become portable, yes, bring one layer then write different asm for different architecture,
like converting asm source to arm asm source.

C is portable in a sense because people build compiler base on iso standard (the 1 layer there)

if there is a ASM iso standard, so every hardware processor designer will follow that standard to offer what could be done by their processor, then ASM will become portable like C
Post 24 Mar 2013, 13:37
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
malpolud wrote:
Then most ASM programs would be perfectly portable since once we design algorithms and understand the way the program works the rewriting will take much less than the first time, so according to you the code could be considered portable Wink


Personally, I define portability as "how much effort you take to make your program run on different machine/OS than where it came from".

Here (ASM coding), the effort can be determined by at least 2 factors:
1. Time to modify vs time to rewrite from scratch.
If the latter is bigger, then it's not portable. Otherwise it's portable. In this case, ASM program can be considered portable, or not.

2. Instruction set
X86, ARM, Sparc etc have their own instruction. Thus by language design, ASM is not portable.

As you can see, portability is not affected by just 1 thing.
Correct me if I'm wrong Smile
Post 24 Mar 2013, 14:18
View user's profile Send private message Reply with quote
qwerc



Joined: 23 Mar 2013
Posts: 3
qwerc
When I said 'portable' I just meant being able to use the source code without lots of manual modifications.

According to me java and c, both are portable with java being a bit more portable. For instance, java executables can work on different platforms (portability in this case is brought by jvm which diminishes the architecture specialties (or negates the differences in the architectures) or does something similar (which I'm not really aware of, being new to programming and hardware). In C, we need to recompile the source code for the specific architecture or hardware (something like jvm is not possible because unlike java, c is not so strict and varies between compilers. Plus, the programs in c are more efficient and less resource hog due to this recompilation needed for each architecture). With 'portability' I loosely meant 'being practically able to use the source with few/no modifications'.

Now coming closer to the hardware, the machine instructions for a specific task vary from one processor architecture to another.
Assembly language is like a macro of machine instructions.
So if we know the processor the ASM was written for, won't it be theoretically possible to have a converter convert it into assembly meant for another processor?
As posted by uart777
Quote:
ASM involves using specific instructions that may not be available on other processors such as division and FP arithmetic.

This may be the reason, assembly cannot be automatically rewritten to another processor's corresponding assembly because the way to achieve the same thing may take a completely different logical approach in another processor.

Now even in C, the code written for windows will have to be modified before being recompiled on linux. Even so it is still considered somewhat portable.
When I say portable I just loosely mean it is practically possible to compile the code with very few modifications.
So if we make the necessary logical modifications in the assembly code and convert the rest into another assembly, can it theoretically be assumed portable (with portable I mean "being able to use most of the code with very less modifications")?
Or are the methods or ways (NOT reffering to the 'methods' as in HLL languages) used in assembly just too unique to an architecture to allow for any automatic conversion?

If I got things right uptil now, I have one more confusion. I don't really understand the level of assembly language. Electrical signals (or machine language) is the lowest level of interaction with the hardware.
Quote:

"converts the assembly code to machine code" -- there is not much conversion going on there.
Basically, the ASM code IS a machine code.

What is the work of an assembler then?

And to sum up the answer to my initial question regarding the portability issue of assembly language, I believe it's because the instructions vary way too much to allow for any substantial auto conversion.
Post 24 Mar 2013, 14:58
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 8864
Location: ˛                             ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣Posts: 334455
sleepsleep
Quote:

What is the work of an assembler then?

translator,
Post 24 Mar 2013, 15:11
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.