flat assembler
Message board for the users of flat assembler.

Index > Main > Assembly change a variable?

Author
Thread Post new topic Reply to topic
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
Alright so doing some programming in 16-bit mode,
just wanted to change a variable at runtime.
Toughest thing to do (for me)
So I make a variable :
prompt db 'Restart',0
and want to change it to
prompt db 'Shutdown',0
at RUNTIME!
So I tried :
mov [prompt],'Shutdown'
But that didn't work Sad
Help would be appreciated
~Sids123

_________________
"Those who can make you believe in absurdities can make you commit atrocities" -- Voltaire https://github.com/Benderx2/R3X
XD
Post 16 Oct 2013, 14:26
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1409
Location: Toronto, Canada
AsmGuru62
In cases like this you need both variables:
Code:
Prompt1 db 'Restart',0
Prompt2 db 'Shutdown',0
    

And then just use the correct one as needed.
Post 16 Oct 2013, 14:43
View user's profile Send private message Send e-mail Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
The 'shutdown' word contains 8 bytes, but you can process only 4 bytes at once. Notice also, that the word "Restart" is only 7 bytes, so there is no free place for the 8-th byte of 'shutdown'.

This all can be solved by several ways and AsmGuru62 already described one solution, suitable if you simply want two possible messages. If you want to do it just for practice, following code may help:

Code:
prompt  db 'Restart', 0, 0  ; one byte more than needed in order to have place enough for 'shutdown'

        mov  dword [prompt], 'Shut'      ; 'prompt' is defined as byte variable
        mov  dword [prompt+4], 'down'    ; that is why 'dword' type keyword is used.
    
Post 16 Oct 2013, 15:54
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 706
Location: Belarus
DimonSoft
IMHO, the largest mistake beginners make when switching from high-level languages to assembler is assuming that data labels are variables. Labels (simplified) are just simple good-old constants with value of some memory address. Actually that's one of the things I try to explain my students before they start writing something more serious than «Hello, world!».
Post 17 Oct 2013, 05:52
View user's profile Send private message Visit poster's website Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
I know one assembler that actually does support this type of thing (not on Intel). I realized the other day that Intel assemblers don't support moves from literals as in there is no syntax that supports it. It would be kind of nice and I don't think it would be too hard if Intel assemblers supported this.

For example what the OP posted:

mov [prompt],'Shutdown'

You could code something like

mov [prompt],=db'Shutdown'

when the assembler sees an = where an operand is supposed to go it knows to assemble an unnamed literal and move its address or contents whichever is appropriate for the context.
Post 22 Oct 2013, 18:15
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
sid123:
Quote:
So I tried :
mov [prompt],'Shutdown'
But that didn't work
It helps to know C. You need a "strcpy" (string-copy) function that copies literal text (array of characters) to a buffer. mov dword [t], 'ABCD' only works for 1-4 characters (0xAABBCCDD). Example (32BIT):
Code:
strcpy:
push ebp
mov ebp, esp    
mov eax, [ebp+8]   ; destiny
mov edx, [ebp+0Ch] ; source
@@:
 mov cl, [edx]     ; copy character
 mov [eax], cl
 test cl, cl       ; until 0
 jz @f
 inc eax           ; next
 inc edx
jmp @b
@@:
mov esp, ebp
pop ebp
ret 8    
Destiny must be an array of characters (or pointer):
Code:
buffer db 64 dup(0) ; text buffer(64)    
Post 22 Oct 2013, 22:00
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 706
Location: Belarus
DimonSoft
dogman wrote:
I know one assembler that actually does support this type of thing (not on Intel). I realized the other day that Intel assemblers don't support moves from literals as in there is no syntax that supports it. It would be kind of nice and I don't think it would be too hard if Intel assemblers supported this.

For example what the OP posted:

mov [prompt],'Shutdown'

You could code something like

mov [prompt],=db'Shutdown'

when the assembler sees an = where an operand is supposed to go it knows to assemble an unnamed literal and move its address or contents whichever is appropriate for the context.

Well, it actually wouldn't be nice. First of all, there's no support for string data types in Intel processors and, obviously, in most RISC-processors as well. I've read somewhere that PDP's had some kind of support, but those were the dark times in the past. Not sure if it was true. But nowadays you need at least a dozen of instructions to copy a string.

Secondly, how are the assemblers supposed to implement the feature? Should they put an inline loop? Or should they insert a call to some kind of strcpy() implementation? Which one? And one should note that some registers will have their values changed after the loop or call: they are used by the algorithm.

Problem #3. Are you working with UTF16? Or ANSI/OEM codepage? Or maybe UTF32? How many people will try to use the feature for copying UTF8-strings? And don't forget about the weird UTF7! Smile

OK, you can push the registers and pop them out and you can specify the format of the string by the "db"-like prefix. Now you have the exact equivalent of strcpy(). But it is not the one you actually need! They've already had it in C and now they've moved to strcpy_s() and other similar functions, which not only take pointers to source and destination but their lengths as well. Otherwise you have a great potential of buffer overrun vulnerabilities. Now how am I supposed to point those sizes to an assembler? The sizes may be constants, values in memory, registers—that's a new branch of generated code each time.

"OK", you can say, "so why not implementing it the same way Delphi does: just supporting the string data type as a native type for compiler?" Well, first of all, there're lots of high-level features in those strings like reference counters, which should also be supported to pretend that strings are native type. Secondly, it wouldn't be an assembler anymore, it is a real compiler now and it is some really weird dialect of Delphi now.

And why do you need assembler to do it for you, if you have Delphi in the first place?
Post 23 Oct 2013, 08:08
View user's profile Send private message Visit poster's website Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
DimonSoft wrote:
dogman wrote:
I know one assembler that actually does support this type of thing (not on Intel). I realized the other day that Intel assemblers don't support moves from literals as in there is no syntax that supports it. It would be kind of nice and I don't think it would be too hard if Intel assemblers supported this.

For example what the OP posted:

mov [prompt],'Shutdown'

You could code something like

mov [prompt],=db'Shutdown'

when the assembler sees an = where an operand is supposed to go it knows to assemble an unnamed literal and move its address or contents whichever is appropriate for the context.

Well, it actually wouldn't be nice. First of all, there's no support for string data types in Intel processors and, obviously, in most RISC-processors as well.


I realize I misunderstood the OP's intent (to move a string rather than the address of the string) and I do know Intel doesn't have string instructions. That's why this kind of assembly notation would be very useful in Intel. A few things have to happen. There has to be some kind of literal pool so that constants can be assembled and not duplicated (the assembler I use does this) and then the right instructions have to be generated. True, for Intel it would be more like a macro than an instruction but it could be implemented in the assembler directly and have it generate whatever instructions (mov, rep etc.) necessary because the assembler does have all the info necessary like the target and source addresses and the length of the string. I find Intel annoying when dealing with strings and so do a lot of other people who are used to other architectures and assemblers. It certainly wouldn't hurt to have this kind of thing in an assembler.

Since you mentioned RISC processors you should be aware that many of the RISC assemblers already have so-called synthetic instructions that actually expand into multiple machine instructions to get around exactly these kinds of ISA limitations. In my opinion they could take it a lot further and actually make the platforms much more usable to the assembly coder. That is where I'm coming from.

DimonSoft wrote:
I've read somewhere that PDP's had some kind of support, but those were the dark times in the past. Not sure if it was true. But nowadays you need at least a dozen of instructions to copy a string.


I don't know what PDPs had but the system I work on has string instructions and the assembler supports this as I suggested. If you don't want to use it nobody's holding a gun to your head. I think it was worth talking about given this forum is for an assembler and not just assembly coders with blinders and earplugs who are all on the board of Intel. Realizing there are other processors in the world is not going to make anybody a worse programmer than he already is. There are plenty of good ideas in other systems and Intel could stand a lot of improvement. A dozen instructions to copy a string? I don't know if that's true in Intel but it sounds pretty appalling.

DimonSoft wrote:
Secondly, how are the assemblers supposed to implement the feature? Should they put an inline loop? Or should they insert a call to some kind of strcpy() implementation? Which one? And one should note that some registers will have their values changed after the loop or call: they are used by the algorithm.


I'm sure if somebody wanted they could implement this. uart777 gave an example how you could do it with a macro but you could support it at an even lower level natively in the assembler.

But first you have to know stuff like this is useful and possible which you never will if all the world is Intel and you never learn anything else.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 23 Oct 2013, 09:35
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 706
Location: Belarus
DimonSoft
dogman wrote:

I'm afraid, you're looking at the problem through the other-architecture-coloured glasses.

Yes, being able to copy the whole string by a single instruction really seems to be cool. But, for example, you've completely ignored my questions about different string formats. It seems like the only way of representing string for you is an array of bytes/words.

Welcome to the world of general-purpose platforms!

1. Different encodings
How do you deal with them? UTF8, UTF16, UTF32, ANSI/OEM, etc. Sure, you should use only one of them internally, but you have to support them anyway.

Shall you extend ISA for each new encoding and hope users upgrade their processors soon? Bad news: they won't.

Shall you use the ISA support only for internal string operations and deal with other encodings manually? Congratulations, you've just created a leaky abstraction: whenever you try to do something non-standard (e.g. stop copying at the end of string AND at the first TAB encountered), you have to reimplement the cool instruction by yourself.

2. Optimization
Optimizing smaller things is much easier. A bit UNIX-style, BTW. How much time does it take to copy a string? "O(n)", you'll probably respond. Now you (as the one who creates the processor) have to deal with Very Slow Instruction in you super-optimized pipeline. Good luck!

OK, you've solved the problem. Now let's add a few more conditions: you have protection and a pagefile. What if the source is in the pagefile? Now your super-cool instruction has stalled the pipeline until the page gets loaded from disk (thousands of ticks). Oops!

3. That's another level of abstraction
Who allocates and frees memory for the string? Memory managers are still implemented by programmers, not by the processor.

You've suggested literal pool. OK, assembler really could combine duplicate literals. But you already CAN do it yourself, it's even easier and more flexible. What if you have two strings with exactly the same value but used differently? Now you should mark the literals some way to make them placed separately. Or you have to copy a string, just in case someone else (e.g. in another module) has the same literal. Why is it so difficult to declare a piece of data by yourself?

-------------------------------------------------------------------------------------

And that's only an attempt to implement strcpy() natively. And the list of problems to solve is far from being complete. And there're tons of other string-handling functions as well.

What Intel provides is a set of bricks that can be combined to form the solution to any string-handling task—this is what programming is, BTW.

What I'm trying to say is that although it can be implemented, it's not really worth that. Leave application-level tasks to applications. Don't try to draw 3D teapots with a single processor instruction unless the only thing your processor does is drawing the teapot. Or just switch to HLL, why using the difficult string-less assembly?
Post 23 Oct 2013, 16:48
View user's profile Send private message Visit poster's website Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
DimonSoft wrote:
dogman wrote:

I'm afraid, you're looking at the problem through the other-architecture-coloured glasses.


You've got that exactly bass-ackwards like everything else you spewed. Oh you're a teacher. Those who can do, those who can't, teach.

DimonSoft wrote:
Yes, being able to copy the whole string by a single instruction really seems to be cool. But, for example, you've completely ignored my questions about different string formats.


Because you're arguing for the sake of arguing. The principle works for any kind of constant you can declare with the assembler. You're just too stupid and self-righteous to see it.

DimonSoft wrote:
It seems like the only way of representing string for you is an array of bytes/words.


No, there are no arrays except in your imagination.

DimonSoft wrote:
Welcome to the world of general-purpose platforms!


You're a pompous ass. I doubt you could code your way out of a paper bag, on any platform. Oh, that's right. You're a "teacher." LOL. Right.

DimonSoft wrote:
How do you deal with them? UTF8, UTF16, UTF32, ANSI/OEM, etc. Sure, you should use only one of them internally, but you have to support them anyway.


Like I said, this is for the assembler to deal with. That's the whole point. You're so used to complexity and failure and inability to solve problems you can't imagine a world where things are actually designed, and work. That's the world I live in.

DimonSoft wrote:
Shall you extend ISA for each new encoding and hope users upgrade their processors soon? Bad news: they won't.


Moron. Only Intel users "upgrade" their processors every year. Other people actually have to think ahead because their stuff has to actually work.

DimonSoft wrote:
Shall you use the ISA support only for internal string operations and deal with other encodings manually? Congratulations, you've just created a leaky abstraction: whenever you try to do something non-standard (e.g. stop copying at the end of string AND at the first TAB encountered), you have to reimplement the cool instruction by yourself.


Shithead. Your embarrassing academic predilection to overcomplicate everything coupled with your complete inability to solve those imaginary problems paints you into a corner, not me. I actually get paid to write code. You get paid (?) to talk about it. Don't give up your open mike spot. Even washing dishes is going to look pretty good for you when they fire your pathetic ass. People who overcomplicate stuff as badly as you do are almost always mentally or emotionally unstable. I would say, keep going to the 12 step program, keep off drugs (except the medicine cabinet of drugs your "doctor" prescribed) and come back when you're clean and sober. And then you can tell us the difference between brown and black leather shoes and the laces and all that good stuff.

DimonSoft wrote:
Who allocates and frees memory for the string? Memory managers are still implemented by programmers, not by the processor.


That's why I said the assembler has to manage a literal pool. Scroll up. This has already been done, before you were born. Just because you can't understand anything doesn't make it go away. It already exists.

And your statement is only true on certain platforms. Again, a know-it-all "academic" making broad, incorrect statements based on all that knowledge you picked up lecturing people on things you know nothing about instead of actually writing code.

DimonSoft wrote:
What Intel provides is a set of bricks that can be combined to form the solution to any string-handling task —this is what programming is, BTW.


Arrogant, know-nothing supercilious punk. I'll bet money you got your ass kicked a lot in grade school.

DimonSoft wrote:
What I'm trying to say is that although it can be implemented, it's not really worth that. Leave application-level tasks to applications. Don't try to draw 3D teapots with a single processor instruction unless the only thing your processor does is drawing the teapot. Or just switch to HLL, why using the difficult string-less assembly?


In summary:

You're a failure, you're stupid, you're obnoxious, you're myopic and wrong, your English is subpar to say it politely, and I feel bad for your so-called students. There are some weirdos on here but you take the cake. I've been coding assembler and getting paid for it while you just send the girl students home crying with your ignorant, pompous sarcasm and the guys probably want to kick your ass. With your repulsive attitude I'm sure some of them eventually will and we can all watch the video on CNN. The only things you seem to be good at are making an ass of yourself in public and lecturing people who's shoes you couldn't shine on your best day. Keep going buddy. Because you're going to wind up shining a lot of shoes for a living.

E P I C...F A I L

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 23 Oct 2013, 18:37
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 706
Location: Belarus
DimonSoft
dogman wrote:
<Tons of butthurt>

Nice try! For absolute success you only need to change your teacher of guesswork.

Now, after you've pumped out your complexes to the forum you can proceed to the guys from… Microsoft… or Intel… or any other widely known company. And tell them about your ideal world of unlimited compatibility, where everything can be implemented anywhere.

As for the readers of the forum, Nuff said.
Post 23 Oct 2013, 20:32
View user's profile Send private message Visit poster's website Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
As a side note, there actually are string instructions in x86 ISA*: ins[b/w/d], outs[b/w/d], cmps[b/w/d/q], movs[b/w/d/q] which can be combined with rep prefix for arbitrary lengths. So another possibility (amongst many others) is to use "rep movsb"; this is what most strcpy's in C use as well but it is applicable to all types with byte granularity.

However, this physical copying has a lot of problems/issues so something along the lines of what AsmGuru62 showed would be the best approach in most cases.

(* Those with SSE4.2 will also have pcmp[e/i]str[i/m])
Post 23 Oct 2013, 21:26
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
Well, I presented a basic ASCII copy to teach the concept and there are many different ways to do this. For long text/files, MMX/XMM 64/128BIT copy on X86 or VFP LS multiple+preload on ARMv7+.

Quote:
Don't try to draw 3D teapots with a single processor instruction unless the only thing your processor does is drawing the teapot.
In the 90s, popular game/graphics author Michael Abrash (ID/Quake) was writing optimized code to draw 3D objects/scenes using old 286-386 CPUs. Many of the systems that I do for programming for dont have video acceleration or it's embedded and there's no documentation. So, I think it's important to understand the algorithms and how to implement them on any system.
Post 24 Oct 2013, 03:23
View user's profile Send private message Reply with quote
uart777



Joined: 17 Jan 2012
Posts: 369
uart777
DimonSoft: Do you have ideas for a universal string structure/class with functions, safety and automatic allocation? Example (on cell phone):
Code:
structure STRING  ; 16 bytes in 32BIT
 void p          ; pointer (should be first/aligned)
 uinteger type    ; 'a8' by default
 uinteger n, size ; length, allocation size
ends ?string    
Post 24 Oct 2013, 05:42
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 706
Location: Belarus
DimonSoft
Quote:
As a side note, there actually are string instructions in x86 ISA*: ins[b/w/d], outs[b/w/d], cmps[b/w/d/q], movs[b/w/d/q] which can be combined with rep prefix for arbitrary lengths.

Just to complete the list, there's also scas[b/w/d]. And yes, these are the bricks which were meant by the phrase
Quote:
What Intel provides is a set of bricks that can be combined to form the solution to any string-handling task—this is what programming is, BTW.


P.S. Thanks for mentioning SSE 4.2, this finally inspired me to dive into learning more about SSE extensions. I haven't really paid much attention to them before.

UPD.
Quote:
DimonSoft: Do you have ideas for a universal string structure/class with functions, safety and automatic allocation? Example (on cell phone):

I'm afraid I don't get the idea of your question, i.e. what am I supposed to answer. I mostly write for Windows and personally prefer using Delphi-like strings with reference counter and actual length at negative offsets and null-termination for WinAPI-compatibility (and I obviously have a set of functions written to manage them). The structure you gave has the same ideas (plus variable length support, I guess) implemented as two separate data structures.
Post 24 Oct 2013, 05:51
View user's profile Send private message Visit poster's website Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
I guess I got it. Thanks FASM community!
Post 27 Oct 2013, 05:07
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


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

Powered by rwasa.