Index
> Main > Assembly change a variable? |
| Author |
|
|
sid123 16 Oct 2013, 14:26
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 
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 |
|||
16 Oct 2013, 14:26 |
|
|
AsmGuru62 16 Oct 2013, 14:43
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. |
|||
|
16 Oct 2013, 14:43 |
|
|
DimonSoft 17 Oct 2013, 05:52
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!».
|
|||
|
17 Oct 2013, 05:52 |
|
|
dogman 22 Oct 2013, 18:15
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. |
|||
|
22 Oct 2013, 18:15 |
|
|
uart777 22 Oct 2013, 22:00
sid123:
Quote: So I tried : 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 Code: buffer db 64 dup(0) ; text buffer(64) |
|||
|
22 Oct 2013, 22:00 |
|
|
DimonSoft 23 Oct 2013, 08:08
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. 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! 
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? |
|||
|
23 Oct 2013, 08:08 |
|
|
dogman 23 Oct 2013, 09:35
DimonSoft wrote:
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! |
|||
|
23 Oct 2013, 09:35 |
|
|
DimonSoft 23 Oct 2013, 16:48
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? |
|||
|
23 Oct 2013, 16:48 |
|
|
dogman 23 Oct 2013, 18:37
DimonSoft wrote:
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! |
|||
|
23 Oct 2013, 18:37 |
|
|
DimonSoft 23 Oct 2013, 20:32
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. |
|||
|
23 Oct 2013, 20:32 |
|
|
cod3b453 23 Oct 2013, 21:26
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]) |
|||
|
23 Oct 2013, 21:26 |
|
|
uart777 24 Oct 2013, 03:23
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. |
|||
|
24 Oct 2013, 03:23 |
|
|
uart777 24 Oct 2013, 05:42
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 |
|||
|
24 Oct 2013, 05:42 |
|
|
DimonSoft 24 Oct 2013, 05:51
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. |
|||
|
24 Oct 2013, 05:51 |
|
|
sid123 27 Oct 2013, 05:07
I guess I got it. Thanks FASM community!
|
|||
|
27 Oct 2013, 05:07 |
|
< Last Thread | Next Thread > |
Forum Rules:
|