Index
> Main > "Virtual" ... beautiful directive ! |
| Author |
|
|
asmcoder 13 Jan 2009, 22:21
[content deleted]
Last edited by asmcoder on 14 Aug 2009, 14:53; edited 1 time in total |
|||
13 Jan 2009, 22:21 |
|
|
vid 14 Jan 2009, 01:36
well, the directive *was* really smart indeed, to solve many issues with single directive...
|
|||
|
14 Jan 2009, 01:36 |
|
|
ouadji 14 Jan 2009, 11:05
Yes ... only syntax, it's true !
But, it's impossible to do with many other assembler. Place a structure in the code, or relating to an address in the kernel ... imposible with MASM. This directive "Virtual" is really specific Fasm and allows great flexibility. (sorry for my English, I'm French) |
|||
|
14 Jan 2009, 11:05 |
|
|
Japheth 14 Jan 2009, 12:42
ouadji wrote: Yes ... only syntax, it's true ! Nonsense! Here's one variant how this could be done in Masm syntax: Code: INFOuP struct Flop dd ? Glop dd ? INFOuP ends ... mov eax , [Boum.Glop] <---- !!! = mov eax , dword [offset TOTO + 4] ... main proc code Boum label INFOuP TOTO: cmp edx , .... code main endp |
|||
|
14 Jan 2009, 12:42 |
|
|
revolution 14 Jan 2009, 13:02
I think the main advantage of virtual is in combination with load and store.
|
|||
|
14 Jan 2009, 13:02 |
|
|
ouadji 15 Jan 2009, 10:11
ok
but ... Code: virtual at FFDFF040h
virtual at ebx + eax with Masm ? |
|||
|
15 Jan 2009, 10:11 |
|
|
asmcoder 15 Jan 2009, 14:08
[content deleted]
Last edited by asmcoder on 14 Aug 2009, 14:53; edited 1 time in total |
|||
|
15 Jan 2009, 14:08 |
|
|
bitRAKE 15 Jan 2009, 16:17
As others have said, virtual solves many problems with one keyword. MASM has assume and label to solve some of those problems, but cannot make decisions at assemble-time based on opcode generation, and code length decisions are limited and cumbersome.
|
|||
|
15 Jan 2009, 16:17 |
|
|
Japheth 15 Jan 2009, 18:07
ouadji wrote:
I'm unsure what you want to achieve. Perhaps Code:
.386
.model flat
s1 struct
org 0ffdff040h
v1 dd ?
v2 dd ?
s1 ends
.code
mov eax, ds:[s1.v1]
end
should be somewhat similar to "virtual at 0ffdff040h". However, it won't be easy for Masm to emulate virtual in conjunction with load. |
|||
|
15 Jan 2009, 18:07 |
|
|
MazeGen 15 Jan 2009, 21:02
Japheth wrote: However, it won't be easy for Masm to emulate virtual in conjunction with load. Hello Japheth, I thought there is no way in MASM to load anything at assemble-time. Can you give me an advice? |
|||
|
15 Jan 2009, 21:02 |
|
|
baldr 15 Jan 2009, 21:16
What about named addressing spaces and scope operator? No more single-byte load/store…
Japheth, virtual at m32 is unbeatable. _________________ "Don't belong. Never join. Think for yourself. Peace." – Victor Stone. |
|||
|
15 Jan 2009, 21:16 |
|
|
Japheth 16 Jan 2009, 09:11
Hi MazeGen,
MazeGen wrote:
Yes, for Masm the code buffer is "write-only", the <load> directive is probably a unique Fasm feature. Tastes a bit "hackish", though, but that might be because I'm biased... |
|||
|
16 Jan 2009, 09:11 |
|
|
DOS386 16 Jan 2009, 14:50
> the <load> directive is probably a unique Fasm feature.
I love it  |
|||
|
16 Jan 2009, 14:50 |
|
|
bitRAKE 17 Jan 2009, 04:51
Japheth wrote: the <load> directive is probably a unique Fasm feature. Tastes a bit "hackish", though _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
17 Jan 2009, 04:51 |
|
|
Japheth 17 Jan 2009, 05:32
DOS386 wrote: > the <load> directive is probably a unique Fasm feature. Congratulations! But may be you should consider to cool down your emotion a bit. Love makes blind, and you will need sharp eyes to find a useful application for this feature ...  |
|||
|
17 Jan 2009, 05:32 |
|
|
baldr 17 Jan 2009, 19:36
bitRAKE,
Injecting code in fasm? This feature could be useful, but it will add another easy way to screw up… Debugging macros is already hard enough. _________________ "Don't belong. Never join. Think for yourself. Peace." – Victor Stone. |
|||
|
17 Jan 2009, 19:36 |
|
|
bitRAKE 18 Jan 2009, 02:46
baldr, nah - it'd be easy - just use the same debugging method used on other code. Deciding what and how to expose the internals would be the real challenge. Well, there is the whole security problem, but let us assume we all have the best intentions (trust must begin somewhere).
|
|||
|
18 Jan 2009, 02:46 |
|
< Last Thread | Next Thread > |
Forum Rules:
|