flat assembler
Message board for the users of flat assembler.

Index > Windows > I have the assembler, now what?

Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author
Thread Post new topic This topic is locked: you cannot edit posts or make replies.
Furs



Joined: 04 Mar 2016
Posts: 1471
Furs
revolution wrote:
Did you miss my post above? In fact a large number of API functions use the SSE/AVX instructions for moving data around (without any arithmetic being done). It is not a tiny minority. I'm not saying it is good or bad, just that there are in fact many functions that require the alignment.
It has to move to the stack otherwise there is no point.

And guys, stop mixing AVX into this, because 16-byte alignment is useless if it needs 32-byte alignment.

revolution wrote:
Anyhow, we have it now. It is what it is. If you want to write code that interfaces with the API then you have to comply or have your code crashing.
Yeah, hence my rant.

system error wrote:
this is where you get the idea wrong. In 64-bit ABI of any kind, the work of aligning the stack is not done by the function but rather the responsibility user codes / callers so that a function is free to do its job without any hassle. So the function do not bloat its code with function prologue and epilogue like your pathetic code is suggesting.

It is nothing different than 32-bit calling conventions where the users / callers need to re-align the stack, especially in CDECL. Same old, same old.
Huh? cdecl doesn't require any stack alignment. It only requires the caller to clean up the stack, which has nothing whatsoever to do with alignment.

And just for the record: you are wrong. The callee (function) will have to adjust the stack for AVX, whether you like it or not.

system error wrote:
You DO know that PUSH is a high-level / complex instruction, right?
Wink
No, I don't know that, because you're wrong.

push is faster than even a simple "sub rsp, 8" on newer CPUs because the latter has 1 extra micro op due to messing up the stack machine.

So yeah, you're pretty clueless it seems.

See: http://stackoverflow.com/questions/36631576/what-is-the-stack-engine-in-the-sandybridge-microarchitecture

Even GCC defaults to use push/pop when it can because it is faster AND smaller (since 2014, see comment on accepted answer): http://stackoverflow.com/questions/4534791/why-does-it-use-the-movl-instead-of-push

Looks like your brain needs an upgrade itself to keep up.

Oh on a sidenote, you do know that rep movsb (yes with a 'b') is the fastest way on newer CPUs to move large amount of data around, right? Don't need SSE for memcpy etc at all anymore.


Looks like we're stuck with an idiotic ABI catering to 2003-era CPUs forever, hence my rant. So please document yourself before speaking.

It is an archaic ABI that cannot be changed anymore and deserves ZERO praise. Heck, it doesn't even work for AVX anyway and any future vector extensions.

The most short-sighted design decision I have ever seen in my life because it affects everything subsequently and cannot "be replaced" since code already uses it.
Post 28 Mar 2017, 14:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
Furs wrote:
It has to move to the stack otherwise there is no point.
Yeah it does. AFACIT it mostly it takes the incoming parameters from the stack and moves them to the outgoing stack for call processing. Or vice-versa. Or both. Testing showed that this was a significant amount faster on the then-current range of 64-bit CPUs. I don't know if this is still true for today's CPUs.
Post 28 Mar 2017, 14:17
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1471
Furs
That's the problem. A calling convention must certainly not be a CPU-specific design, same reason most APIs in Windows are not tied to a particular version of Windows. It must be a clean, extensible design, that uses simplest possible path to achieve a goal, since you don't know what will happen in the future. It is stupid to make something that caters to one CPU and will apply, now and in the future, to any other processor by design. Such design is flawed.

Remember the 'rep ret' because of AMD CPUs? Imagine if that was part of the ABI (somehow).

That's what makes its design idiotic.
Post 28 Mar 2017, 14:19
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
@Furs, alignment or not, 32-bit calling conventions stiil require some extra chores dealing with functions enter and exit. It's the same thing with 64-bit ABI. They just do it differently for different purposes. So whatever you're barking about 64-bit does apply to 32-bit as well. No point in barking.

Again you took the 64-bit ABI from a distroted point of view. If you looked at from stack programming, you may have a point (but still rather clueless) with SandyBridge stack engine. But the 64-bit ABI doesn't see its fastcall calling convention from stack management of the processor. The ABI design philosophy tries to avoid the stack programming or to put it in minimal use and take the RSP as an ordinary pointer of memory. There's actually no Stack semantic involved. Look, do you see anything "stacky" about this below?

Code:
sub rsp,20
mov 
mov 
mov    


All I can see from the above is pure ALU and memory transfers. No stack engine, stack frame or stack overhead involved. So there's no point barking about the performance of the 64-bit ABI when you see it wrong in the first place. There's a reason people call it FASTCALL rather than stack call.

Just because you can't code in 64-bit, that doesn't mean system designers are wrong.
Post 28 Mar 2017, 16:51
View user's profile Send private message Reply with quote
C0deHer3tic



Joined: 25 Mar 2017
Posts: 49
C0deHer3tic
Hello everyone,

Below I coded two programs. I have been studying as much as I know, and used the debugger, as well as compiled my C program into assembly code, which I must say is highly confusing to me. Shocked

Here is the C program:

Code:
#include <stdio.h>

int main()
{
        int a, b, c;

        a = 23;
        b = a + a;
        c = b * a;

        printf("%d\n",c ); //1058

        return 0;
}
    


And here is the assembly program:


Code:
format PE console
entry start

include 'win32a.inc'
section '.idata' import data readable
 
library kernel32, 'kernel32.dll', \
        msvcrt,'msvcrt.dll'

import kernel32, \
       ExitProcess,'ExitProcess'
 
import  msvcrt, \
        printf, 'printf'


section '.data' readable  writeable

results db "%d",1010b,0

a dd 23
b dd ?
c dd ?

section '.main' code readable
start:
        mov     eax,[a]
        add     eax,[a]
        mov     [b], eax
        mov     ebx,[b]
        imul    ebx,[a]
        mov     [c],ebx

        push    [c]
        push    results
        call    [printf]
        add     esp, 4
        push    0
        call    [ExitProcess]
    


I would love to know how to input my own variables manually, instead of programming it in the program. I rather get the user input instead of relying on hard coded variables.

Please advise me so I can do this the right way. Razz

- Sincerely, C0d3Her3tic

_________________
- Just because something is taught one way, does not mean there is not a different way, possibly more efficient. -
Post 28 Mar 2017, 19:22
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1471
Furs
system error wrote:
@Furs, alignment or not, 32-bit calling conventions stiil require some extra chores dealing with functions enter and exit. It's the same thing with 64-bit ABI. They just do it differently for different purposes. So whatever you're barking about 64-bit does apply to 32-bit as well. No point in barking.

Again you took the 64-bit ABI from a distroted point of view. If you looked at from stack programming, you may have a point (but still rather clueless) with SandyBridge stack engine. But the 64-bit ABI doesn't see its fastcall calling convention from stack management of the processor. The ABI design philosophy tries to avoid the stack programming or to put it in minimal use and take the RSP as an ordinary pointer of memory. There's actually no Stack semantic involved. Look, do you see anything "stacky" about this below?

Code:
sub rsp,20
mov 
mov 
mov    


All I can see from the above is pure ALU and memory transfers. No stack engine, stack frame or stack overhead involved. So there's no point barking about the performance of the 64-bit ABI when you see it wrong in the first place. There's a reason people call it FASTCALL rather than stack call.

Just because you can't code in 64-bit, that doesn't mean system designers are wrong.
WTF are you talking about? fastcall is a 32-bit calling convention, like cdecl or stdcall.

And it has nothing to do with alignment of the stack. In fact, it has nothing to do with the stack to begin with. fastcall is called that way because it passes parameters in registers instead of on the stack (which has nothing to do with alignment or whatever you talk about). Also, your example with the ALU is for what? Nothing to do with alignment, you can use dumb bloated code without 'push' instructions in 32-bit too if you want. (you can also do that in 64-bit without aligning the stack as well)

And yes designers are dumb, it's one of those cases of short-sightedness that unfortunately is one of the worst in long-standing impact, because it makes us stuck forever with it. Now, even new code utilizing the latest vector instructions will suffer from it, because it has to realign the stack anyway, so 16-byte alignment is LITERALLY nothing but a waste. But then again, this fiasco was designed by AMD and MS just adopted it later, why am I not surprised it's so shit?

Keep barking about me being unable to code in 64-bit though, you really do a good job at strawman fallacies: https://en.wikipedia.org/wiki/Straw_man

At this point I know you're just a troll or just dumb and don't even know what he's talking about (both the push thing, then the cdecl, and now fastcall thing), and anyway this started from it being more complicated to code in for a newbie like the OP in this thread + a personal rant. (MS one makes it doubly worse, not just alignment, but Shadow Space too, so yeah, it's more difficult for newbies), so not going to blow this out anymore, sorry CodeHeretic for this dragged rant in your thread.


If designers were so damn good all the time as you think they are (lol), then why are some instructions so slow in x86 like xlat? Or other instructions that nobody uses (except for super small code size optimizations). Yeah it's called lacking foresight. At that time, it seemed like a good idea. Too bad it was a shit idea.
Post 28 Mar 2017, 19:58
View user's profile Send private message Reply with quote
C0deHer3tic



Joined: 25 Mar 2017
Posts: 49
C0deHer3tic
It is okay, Furs and the rest. It is all rather intriguing. Razz

I am eagerly reading everything, although it is all beyond me. Haha!

I hope my questions are not too bothersome. I am after all, a beginner! Very Happy
Post 28 Mar 2017, 20:03
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1471
Furs
C0deHer3tic wrote:
I would love to know how to input my own variables manually, instead of programming it in the program. I rather get the user input instead of relying on hard coded variables.

Please advise me so I can do this the right way. Razz
Ok, I need to go soon but looking at your code I can tell you a few things:

The variables you defined are global (those with 'dd'), it's like defining global variables in C.

The [] memory operand is simply a dereference. Learning assembly made me actually understand C pointers so much better when I did, so here's how it works for me:


Imagine your RAM addressing space is a huge array, to cover your entire RAM. For example, for 32-bit programs, imagine it's a 4 GB array. So each variable in RAM has an index into this 'RAM' array, just like you'd use an index in a C array.

So when you type this in assembly:

Code:
mov eax, [address]    
You simply get the 32-bit (dword) found at index 'address' of RAM (note that this index is byte relative, not dword, that is, [address+1] is one byte higher in memory, not 4!!)

Basically the [] is dereference, just like an array in C.

A pointer is the same thing: it simply holds the "index" or "address" into the RAM array. So:
Code:
mov eax, [ebx]    
treats 'ebx' as a pointer, and you get the 32-bit value it points to, into eax.

There's nothing extra or special about pointers, they're just a byte index into this RAM array -- that's their storage (32-bit or 64-bit or w/e depending on architecture). That's what they hold.

So, in your case, you should allocate the variables on the stack. esp is the "stack pointer" because it points to the current address of the stack, somewhere in RAM.

The stack grows downward so when you push something, esp gets decremented by 4 (or 8 in 64-bit). It's like going "backwards" in memory. Something like:

Code:
mov eax, [esp+4]    
Gets the 32-bit variable found 4 bytes above the current stack pointer. This one stores it:
Code:
mov [esp+4], eax    


EDIT: Oh and to finish this small part up, you should never generally address things below the stack pointer (except in 64-bit with red zone, again, don't bother with that yet). So NEVER do:

Code:
mov eax, [esp-4]    
or similar, because there's no guarantee that data is "safe". (your program can get interrupted by the OS and the OS could modify data below the stack before returning back to your program)

At most, use [esp] for storing data. If you need more local variable space on the stack, simply subtract 'esp' or 'push' some more, i.e.:

Code:
sub esp, 8      ; makes space for 8 more bytes
push something  ; same thing but decrements esp by 4 AND places a value at the new [esp]
    
Normally, people do a 'sub esp, X' at the start of a function, to cover all local variables. It's easier that way, since you won't modify 'esp', so you can address all of them with same offsets.

To help you not hardcode offsets into your program, you can use symbolic constants (an assembler thing, sort of like macros in C), so:

Code:
some_var = 4
other_var = 8

; and then do this
mov eax, [esp+some_var]    ; same as [esp+4]    
The "some_var = 4" are not assembly instructions, so they don't do anything by themselves, same reason a #define in C doesn't do anything, until it is used.
Post 28 Mar 2017, 20:08
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
Furs wrote:
system error wrote:
@Furs, alignment or not, 32-bit calling conventions stiil require some extra chores dealing with functions enter and exit. It's the same thing with 64-bit ABI. They just do it differently for different purposes. So whatever you're barking about 64-bit does apply to 32-bit as well. No point in barking.

Again you took the 64-bit ABI from a distroted point of view. If you looked at from stack programming, you may have a point (but still rather clueless) with SandyBridge stack engine. But the 64-bit ABI doesn't see its fastcall calling convention from stack management of the processor. The ABI design philosophy tries to avoid the stack programming or to put it in minimal use and take the RSP as an ordinary pointer of memory. There's actually no Stack semantic involved. Look, do you see anything "stacky" about this below?

Code:
sub rsp,20
mov 
mov 
mov    


All I can see from the above is pure ALU and memory transfers. No stack engine, stack frame or stack overhead involved. So there's no point barking about the performance of the 64-bit ABI when you see it wrong in the first place. There's a reason people call it FASTCALL rather than stack call.

Just because you can't code in 64-bit, that doesn't mean system designers are wrong.
WTF are you talking about? fastcall is a 32-bit calling convention, like cdecl or stdcall.

And it has nothing to do with alignment of the stack. In fact, it has nothing to do with the stack to begin with. fastcall is called that way because it passes parameters in registers instead of on the stack (which has nothing to do with alignment or whatever you talk about). Also, your example with the ALU is for what? Nothing to do with alignment, you can use dumb bloated code without 'push' instructions in 32-bit too if you want. (you can also do that in 64-bit without aligning the stack as well)

And yes designers are dumb, it's one of those cases of short-sightedness that unfortunately is one of the worst in long-standing impact, because it makes us stuck forever with it. Now, even new code utilizing the latest vector instructions will suffer from it, because it has to realign the stack anyway, so 16-byte alignment is LITERALLY nothing but a waste. But then again, this fiasco was designed by AMD and MS just adopted it later, why am I not surprised it's so shit?

Keep barking about me being unable to code in 64-bit though, you really do a good job at strawman fallacies: https://en.wikipedia.org/wiki/Straw_man

At this point I know you're just a troll or just dumb and don't even know what he's talking about (both the push thing, then the cdecl, and now fastcall thing), and anyway this started from it being more complicated to code in for a newbie like the OP in this thread + a personal rant. (MS one makes it doubly worse, not just alignment, but Shadow Space too, so yeah, it's more difficult for newbies), so not going to blow this out anymore, sorry CodeHeretic for this dragged rant in your thread.


If designers were so damn good all the time as you think they are (lol), then why are some instructions so slow in x86 like xlat? Or other instructions that nobody uses (except for super small code size optimizations). Yeah it's called lacking foresight. At that time, it seemed like a good idea. Too bad it was a shit idea.


I can't really tell whether you're an idiot or an assembly programmer wannabe because your points are way off. I wasn't being serious attending to your stupidity so I responded and quoted in just short sentences. I wasn't really that interested to attend to INCOMPETENT wannabe.

Just admit it that you can't code in 64-bit and try to put the blame on others. Your case is similar to 16-bit programmers trying to blame the lame design of 32-bit calling conventions simply because they didn't understand it. That's you. If you are not competent enough to use 64-bit calling conventions, just admit it openly.

WE, the rest of the programmers have no problems understanding and using the 64-bit ABIs so far




Laughing
Post 28 Mar 2017, 20:51
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
C0deHer3tic wrote:
Hello everyone,

Below I coded two programs. I have been studying as much as I know, and used the debugger, as well as compiled my C program into assembly code, which I must say is highly confusing to me. Shocked

Here is the C program:

Code:
#include <stdio.h>

int main()
{
        int a, b, c;

        a = 23;
        b = a + a;
        c = b * a;

        printf("%d\n",c ); //1058

        return 0;
}
    


And here is the assembly program:


Code:
format PE console
entry start

include 'win32a.inc'
section '.idata' import data readable
 
library kernel32, 'kernel32.dll', \
        msvcrt,'msvcrt.dll'

import kernel32, \
       ExitProcess,'ExitProcess'
 
import  msvcrt, \
        printf, 'printf'


section '.data' readable  writeable

results db "%d",1010b,0

a dd 23
b dd ?
c dd ?

section '.main' code readable
start:
        mov     eax,[a]
        add     eax,[a]
        mov     [b], eax
        mov     ebx,[b]
        imul    ebx,[a]
        mov     [c],ebx

        push    [c]
        push    results
        call    [printf]
        add     esp, 4
        push    0
        call    [ExitProcess]
    


I would love to know how to input my own variables manually, instead of programming it in the program. I rather get the user input instead of relying on hard coded variables.

Please advise me so I can do this the right way. Razz

- Sincerely, C0d3Her3tic


Use "scanf" or "gets" or "getchar". Import "scanf" just like the way you import "printf". Just different types and numbers of arguments. Looks like you are progressing to interactive programming already.
Post 28 Mar 2017, 20:58
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
Furs wrote:
C0deHer3tic wrote:
I would love to know how to input my own variables manually, instead of programming it in the program. I rather get the user input instead of relying on hard coded variables.

Please advise me so I can do this the right way. Razz
Ok, I need to go soon but looking at your code I can tell you a few things:

The variables you defined are global (those with 'dd'), it's like defining global variables in C.

The [] memory operand is simply a dereference. Learning assembly made me actually understand C pointers so much better when I did, so here's how it works for me:


Imagine your RAM addressing space is a huge array, to cover your entire RAM. For example, for 32-bit programs, imagine it's a 4 GB array. So each variable in RAM has an index into this 'RAM' array, just like you'd use an index in a C array.

So when you type this in assembly:

Code:
mov eax, [address]    
You simply get the 32-bit (dword) found at index 'address' of RAM (note that this index is byte relative, not dword, that is, [address+1] is one byte higher in memory, not 4!!)

Basically the [] is dereference, just like an array in C.

A pointer is the same thing: it simply holds the "index" or "address" into the RAM array. So:
Code:
mov eax, [ebx]    
treats 'ebx' as a pointer, and you get the 32-bit value it points to, into eax.

There's nothing extra or special about pointers, they're just a byte index into this RAM array -- that's their storage (32-bit or 64-bit or w/e depending on architecture). That's what they hold.

So, in your case, you should allocate the variables on the stack. esp is the "stack pointer" because it points to the current address of the stack, somewhere in RAM.

The stack grows downward so when you push something, esp gets decremented by 4 (or 8 in 64-bit). It's like going "backwards" in memory. Something like:

Code:
mov eax, [esp+4]    
Gets the 32-bit variable found 4 bytes above the current stack pointer. This one stores it:
Code:
mov [esp+4], eax    


EDIT: Oh and to finish this small part up, you should never generally address things below the stack pointer (except in 64-bit with red zone, again, don't bother with that yet). So NEVER do:

Code:
mov eax, [esp-4]    
or similar, because there's no guarantee that data is "safe". (your program can get interrupted by the OS and the OS could modify data below the stack before returning back to your program)

At most, use [esp] for storing data. If you need more local variable space on the stack, simply subtract 'esp' or 'push' some more, i.e.:

Code:
sub esp, 8      ; makes space for 8 more bytes
push something  ; same thing but decrements esp by 4 AND places a value at the new [esp]
    
Normally, people do a 'sub esp, X' at the start of a function, to cover all local variables. It's easier that way, since you won't modify 'esp', so you can address all of them with same offsets.

To help you not hardcode offsets into your program, you can use symbolic constants (an assembler thing, sort of like macros in C), so:

Code:
some_var = 4
other_var = 8

; and then do this
mov eax, [esp+some_var]    ; same as [esp+4]    
The "some_var = 4" are not assembly instructions, so they don't do anything by themselves, same reason a #define in C doesn't do anything, until it is used.


All he needs to know is about scanf to create an interactive program. You don't have to be that verbose. He's a newbie. U mad bro or are u trying to prove to everybody that you can actually code?
Post 28 Mar 2017, 21:05
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
hehehe
Post 28 Mar 2017, 21:08
View user's profile Send private message Reply with quote
Trinitek



Joined: 06 Nov 2011
Posts: 257
Trinitek
system error wrote:
U mad bro or are u trying to prove to everybody that you can actually code?
Let's try to act like adults, gentlemen.

@Her3tic In addition to the suggested C scanner functions, you can also take a look at GetCommandLine to get the command-line arguments.
Post 28 Mar 2017, 21:40
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1471
Furs
system error wrote:
Just admit it that you can't code in 64-bit and try to put the blame on others. Your case is similar to 16-bit programmers trying to blame the lame design of 32-bit calling conventions simply because they didn't understand it. That's you. If you are not competent enough to use 64-bit calling conventions, just admit it openly.
Oh, I regret actually trying to even talk to a stupid kid like you, since this confirms it.

I'm sure one of my complaint about it not using 'rax' register to pass as first parameter is also my lack of understanding. The ABI is so well designed, 'rax' is not used for anything as input and is trashed / clobbered for output. Waste of potential register. Obviously I have difficulties using 'rcx' instead of 'rax', it's damn hard to type 'c' instead of 'a', hence my complaint about that too. Requires someone of your childish expertise to do that. You probably don't even know what the red zone is since MS ABI doesn't even use it. Sad joke of a child.


As for interactive, I misread what he meant. I thought he wanted to place his values in variables, instead of hard-coding the values as constants like he did before.
Post 28 Mar 2017, 23:09
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
Furs wrote:
I'm sure one of my complaint about it not using 'rax' register to pass as first parameter is also my lack of understanding. The ABI is so well designed, 'rax' is not used for anything as input and is trashed / clobbered for output. Waste of potential register.


Any competent 64-bit programmers don't really bother whether it is RAX, RZX, RKK, KKK or whatever registers given to them. It never and should never be a problem. If you can't use registers other than RAX, then let it go. Invent your own so-called "smart" calling conventions then let me rant about it by calling you stupid in return.

Just to let you know that certain variadic functions like printf do require RAX as parameter. Linux 64-bit ABI / syscall uses RAX from start to finish. Seems like you don't have the slightest idea about the 64-bit ABI afterall!.


Furs wrote:
Obviously I have difficulties using 'rcx' instead of 'rax', it's damn hard to type 'c' instead of 'a', hence my complaint about that too. Requires someone of your childish expertise to do that. You probably don't even know what the red zone is since MS ABI doesn't even use it. Sad joke of a child.


Bad news 1! Linux ABI uses RDI!
Bad news 2! I never mentioned red zone in any of my comment. You're exaggerating.

Furs wrote:
As for interactive, I misread what he meant. I thought he wanted to place his values in variables, instead of hard-coding the values as constants like he did before.


That's because you're extemely mad at me for giving you some schooling on 64-bit programming.
Post 28 Mar 2017, 23:38
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
I'm late to this discussion, only skimmed it, but you probably don't need my advice anyways (as I don't grok Windows).

C0deHer3tic wrote:
I am an experienced programmer in several languages and now I have decided it is time to tackle assembly.


If you're already proficient in several HLLs, then why bother with x86 assembly? Sure, assembly can be fun, but it's also very error-prone. You'll constantly be living inside a debugger.

I also wonder if this is a misguided attempt to "speed up" or "optimize" your software. Probably not worth it, you're most likely headed in the wrong direction. The way things are going these days, discrete specialized assembly instructions can (sometimes) speed things up noticeably, but overall there are betters methods to improve things. (Think SMP or multi-threading. Heck, some compilers still allow inline asm anyways, e.g. FPC. Or just use intrinsics in GCC et al. Heck, just find a better algorithm!) And optimizing for size is almost pointless if your preferred OS already takes gigs of space.

Quote:
I chose FASM to start with. Reasons are that I was able to compile the code on my system which is Windows 8, 64 bit of course. I have tried many assembly language books which unfortunately require me to run the compiled code in emulators. The example code in FASM works; compiling and running smoothly. Most of it is GUI, which is okay, however console is more ideal to me.


You also said this:

Quote:

I see it pointless to program in a language, if all I can do is run it on a system not used in today's computing. 16 bit is hardly compatible now.


Emulators aren't that bad, and VT-X is baked into (most) x86 hardware, hence it's not as "slow" as it could be (e.g. VBox or KVM). Heck, Win8 (64-bit Pro) already has Hyper-V. While I do indeed enjoy DOS (and 16-bit), I'm not actively encouraging that here. I'm just saying, emulators aren't too bad.

But overall I think you're not looking at the big picture. You don't want "obsolete", but everything is obsoleted eventually. Win8 is from 2012, and IA-32 (despite what some have told you) is indeed "obsolete" and much less popular. Yes, 32-bit is going away "eventually". So you're (almost) probably wasting your time (IMO!) if you "seriously" want to learn that which isn't going to last anyways.

(Granted, you already know HLLs, so it's not pressing.) Portability is a better goal than cpu-specific stuff, even if (for now) x86 is fairly ubiquitous. Of course, you can always optimize small bottlenecks in assembly, if bored, while falling back to portable code for other arches.

Quote:

I would like a beginner tutorial to start assembly in Fasm with a basic teaching like a simple hello world to print to console until it covers the entire scope of the assembly language with examples and exercises preferably. NO GUI PLEASE.


I can think of two free books and one very cheap ($5 digital) one:



Honestly, even though I haven't done it myself, I would advise you to learn Linux 64-bit instead, presumably with Seyfarth's book (*nix edition, natch). BTW, why didn't you upgrade to Win10? It runs Linux 64-bit binaries now. Well, there's half my point, binaries will run on both, so it's a good target (maybe). Hey, you didn't want GUI anyways. And, while I hate it, I do think 64-bit is better to learn than 32-bit (although it's not criminally wrong either way).
Post 29 Mar 2017, 01:05
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
C0deHer3tic wrote:
No emulators needed. And no Linux. I need to learn this on windows. I don't want to hook C or any other language. Is this at all possible?


Oops, missed this part. Still, I think it's overly ambitious, maybe even foolish, to want to avoid C or Linux entirely. The Windows and Linux kernels are written in C/C++ (even FreeDOS is), so I don't think it's wrong to utilize them to some degree. Most people don't want to totally reinvent the wheel, e.g. write their own printf(). There's nothing wrong with relying on libc.

I realize I'm being overly pessimistic here, but assembly is not an easy solution to anything. Often times you really don't need it, and it's very error-prone. It's not wrong to learn, but it is somewhat tedious and making things harder.
Post 29 Mar 2017, 01:12
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
Furs wrote:
EDIT: Oh and to finish this small part up, you should never generally address things below the stack pointer (except in 64-bit with red zone, again, don't bother with that yet). So NEVER do:

Code:
mov eax, [esp-4]    
or similar, because there's no guarantee that data is "safe". (your program can get interrupted by the OS and the OS could modify data below the stack before returning back to your program)
In any protected OS the zone below the stack is perfectly safe for user mode programs to use in regards to worrying about the OS clobbering it. The x86 CPU provides for 4 independent stack pointers, one for for each privilege level. But one does still need to be aware of certain things when using that stack zone, push and call will overwrite any data there.

It is also of note that you can use the stack pointer (ESP/RSP) as a general purpose computing register without causing any problem to the OS. Your stack pointer can even be 0x0000, or any other value you want, and the OS won't crash. But at some point you need to recover the original value before doing calls or pushes and that will usually require some global variable (and that often also precludes multi-threading).
Post 29 Mar 2017, 01:26
View user's profile Send private message Visit poster's website Reply with quote
C0deHer3tic



Joined: 25 Mar 2017
Posts: 49
C0deHer3tic
rugxulo wrote:
If you're already proficient in several HLLs, then why bother with x86 assembly? Sure, assembly can be fun, but it's also very error-prone. You'll constantly be living inside a debugger.


I am looking to learn assembly, no matter the costs. I understand that it is more difficult.

Quote:
I also wonder if this is a misguided attempt to "speed up" or "optimize" your software. Probably not worth it, you're most likely headed in the wrong direction.


It is not, and by any means was a way to speed up and/or optimize. I am merely curious in learning the language on my current platform.

Quote:
Emulators aren't that bad, and VT-X is baked into (most) x86 hardware, hence it's not as "slow" as it could be (e.g. VBox or KVM). Heck, Win8 (64-bit Pro) already has Hyper-V. While I do indeed enjoy DOS (and 16-bit), I'm not actively encouraging that here. I'm just saying, emulators aren't too bad.


I agree, emulators are not bad. I never said they were. I am trying to code and run in windows 8 64 bit. My platform.

Quote:
But overall I think you're not looking at the big picture. You don't want "obsolete", but everything is obsoleted eventually.


I don't want to code my programs that can't even run in my current working environment. This does not mean forever, but for now. I am not sure why you assume so much of what I am saying and asking.

I appreciate the link to the books. I will delve into them if I can.

Quote:
Honestly, even though I haven't done it myself, I would advise you to learn Linux 64-bit instead, presumably with Seyfarth's book (*nix edition, natch).


I must ask why advise me something that you yourself have not even done? What are the benefits? Will it help me in a windows environment? Linux is another plan for me, I have several distros, but I needed a windows tutorial for the sake of learning and running code on my windows platform.

Quote:

BTW, why didn't you upgrade to Win10? It runs Linux 64-bit binaries now. Well, there's half my point, binaries will run on both, so it's a good target (maybe). Hey, you didn't want GUI anyways.


I hate windows. I bought a laptop with windows 8 already installed. It serves its purpose, for games, music software, etc. Yes I know Linux has good DAWs and WINE, etc. I have windows 8, and it is alright with me. Linux is on another computer. Windows 10 may offer better, however the underlining OS is far from secure. But that is another topic altogether, and how much I would love to chat about the vulnerabilities, I will digress from that possible tangent.

Once again you say something is better, but show your dislike for it...

Quote:
And, while I hate it, I do think 64-bit is better to learn than 32-bit (although it's not criminally wrong either way).


I am rather confused by this.

Thank you everyone for your responses.

I will look into the the GetCommandLine, and the rest.

I am looking at all of that code, and reading this thread. Thanks to you all, I am gaining knowledge, and I appreciate all of your endeavors. Razz

- Sincerely, C0deHer3tic

_________________
- Just because something is taught one way, does not mean there is not a different way, possibly more efficient. -
Post 29 Mar 2017, 01:44
View user's profile Send private message Reply with quote
C0deHer3tic



Joined: 25 Mar 2017
Posts: 49
C0deHer3tic
I have a possible ridiculous query. Is it possible to use stand alone assembly code to print stdout, and get stdin?

Or will I have to use C functions in the FASM framework?
Post 29 Mar 2017, 03:38
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic This topic is locked: you cannot edit posts or make replies.

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6  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 cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.