flat assembler
Message board for the users of flat assembler.
Index
> Main > rb fasm syntax Goto page 1, 2 Next |
Author |
|
revolution 17 Jun 2009, 03:33
rb = reserve bytes.
Code: rb 100 ;place 100 bytes into the code Code: db 100 dup (?) |
|||
17 Jun 2009, 03:33 |
|
iic2 17 Jun 2009, 04:34
I keep up better by using dd and db. It a matter of appeal i guest.
|
|||
17 Jun 2009, 04:34 |
|
GhostXoPCorp 17 Jun 2009, 04:49
it just puts 100 spaces in the code?
_________________ Oh that divide overflow. Just jumps out of the bushes every time to scare the day lights out of me. |
|||
17 Jun 2009, 04:49 |
|
revolution 17 Jun 2009, 04:53
GhostXoPCorp wrote: it just puts 100 spaces in the code? |
|||
17 Jun 2009, 04:53 |
|
bitRAKE 17 Jun 2009, 05:14
Code: MyData rb 100 |
|||
17 Jun 2009, 05:14 |
|
GhostXoPCorp 17 Jun 2009, 07:50
is this a better option in making buffers?
_________________ Oh that divide overflow. Just jumps out of the bushes every time to scare the day lights out of me. |
|||
17 Jun 2009, 07:50 |
|
revolution 17 Jun 2009, 08:08
Better option than what?
|
|||
17 Jun 2009, 08:08 |
|
GhostXoPCorp 17 Jun 2009, 17:16
is rb a better option for making buffers for getting keys and other stuff that needs stored in buffers
_________________ Oh that divide overflow. Just jumps out of the bushes every time to scare the day lights out of me. |
|||
17 Jun 2009, 17:16 |
|
iic2 17 Jun 2009, 21:04
You're talking about gathering -up your security files or needing organization, etc? I really don't think it makes no difference, they both work!... but I would never overlook any previous response which carries it own weight in gold.
I like db and dd because as well as FASM, other ASM communities also carry thousands of top-of-the-line examples that will teach you *minumun* the advanced stuff so fast it's embarrassing. This is masm32. I don't like preliminaries, I like light/warp speed, so I go one-below where the (real) action is I like keeping things as simple as possible when it's time to translate, with-out the need of involving other lang to get a simple job done. |
|||
17 Jun 2009, 21:04 |
|
Borsuc 17 Jun 2009, 22:49
GhostXoPCorp wrote: it just puts 100 spaces in the code? _________________ Previously known as The_Grey_Beast |
|||
17 Jun 2009, 22:49 |
|
revolution 18 Jun 2009, 00:07
Borsuc wrote: On the other hand db will surely put that data in your executable. Code: db ? |
|||
18 Jun 2009, 00:07 |
|
Borsuc 18 Jun 2009, 00:29
revolution wrote: That is wrong. See the second post above. db can also put uninitialised data _________________ Previously known as The_Grey_Beast |
|||
18 Jun 2009, 00:29 |
|
MatQuasar 01 Mar 2024, 17:15
I have two different programs which reserve bytes, but strange, one of the EXE remains small while another gets bigger.
Code: section '.data' data readable writable _buffer rb 640*1024 On what occasion the reserve bytes are expanded and occupied the EXE file? |
|||
01 Mar 2024, 17:15 |
|
revolution 01 Mar 2024, 17:23
If you have initialised values after uninitialised data then it all gets included.
Code: rb 1 shl 24 ; uninitialised db 0 ; this is an initialised datum and must be output so all previous data in also included rb 1 shl 24 ; uninitialised at the end so it doesn't need to be included |
|||
01 Mar 2024, 17:23 |
|
macomics 01 Mar 2024, 17:24
If other declarations appear after the declared rb via db/dw/etc (other than db ?), then the entire buffer volume will have to be written to the file because initialized data will appear after it.
|
|||
01 Mar 2024, 17:24 |
|
MatQuasar 01 Mar 2024, 17:28
Thanks for the clues, I am starting to understand:
Code: BUFFER_SIZE = 640 * 1024 section '.data' readable writable _buffer rb BUFFER_SIZE _offset dd ? ...doesn't expand the EXE. But, Code: BUFFER_SIZE = 640 * 1024 section '.data' readable writable _buffer rb BUFFER_SIZE _offset dd 0 ...expands the EXE by 640KB. So the best practice is put initialized values before uninitialized data? Next time I should do this. |
|||
01 Mar 2024, 17:28 |
|
macomics 01 Mar 2024, 17:32
MatQuasar wrote: So the best practice is put initialized values before uninitialized data? |
|||
01 Mar 2024, 17:32 |
|
revolution 01 Mar 2024, 18:11
MatQuasar wrote: So the best practice is put initialized values before uninitialized data? Some OS loaders will zero-initialised the uninitialised memory sections on startup, other OSes might not. Some do zeroing anyway but don't guarantee it, so you still have to make sure that your code can work if the buffer isn't all zeros on startup. Aside: fasm also makes any included uninitialised buffer all zeros, but I haven't seen anything in the docs that explicitly states that it will. Perhaps I missed it, and it is guaranteed, but probably best not to reply upon it. |
|||
01 Mar 2024, 18:11 |
|
Mike Gonta 02 Mar 2024, 15:12
revolution wrote: Some OS loaders will zero-initialised the uninitialised memory sections on startup, other OSes might not. revolution wrote: Some do zeroing anyway but don't guarantee it, so you still have to make sure that your code can work if the buffer isn't all zeros on startup. revolution wrote: Aside: fasm also makes any included uninitialised buffer all zeros, but I haven't seen anything in the docs that explicitly states that it will. |
|||
02 Mar 2024, 15:12 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.