flat assembler
Message board for the users of flat assembler.
Index
> IDE Development > What if the code section is writeable? |
Author |
|
decard 12 Oct 2003, 20:07
Hmmm... the problem is complicated. Mixing data and code isn't a very good choice for bigger projects IMO. Think about uninitialized data... Usually this is solved by linker, in which case each library can have its data section which will be linked with other data sections, but in this case we have to declare all data in main sourcefile. I don't know which solution is better, but I vote for storing everyting in one data section
|
|||
12 Oct 2003, 20:07 |
|
scientica 13 Oct 2003, 04:45
My say:
one .bss section last in the code with all uninitialised data ('it will reduce the size of the exe* on disk), one .data (or .strings) which contans all strings (and other initialise data), having a blend code/data section has some (dis)advantages: Bad pointers can make damages to the code that arent noticed (where as a "guarded" code section would GPF on write). The advantage is that you can place variables any where in the code, but that could also risc reducing readabillity. You can use SMC, which might can have it's advantages. _________________ ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn |
|||
13 Oct 2003, 04:45 |
|
Joshua 13 Oct 2003, 04:56
Quote:
Quote:
Quote:
When i hear things like this, i can't help to advertise one of the macro's i've written: Sections.inc It can resolve the wasted space of uninitialized data when using one section, by automaticly relocating it to the end of the exe, thus getting the best of both worlds: No includes and no wasted space (the macro can also relocate initialized data if you want it to) See this thread for more information: http://board.flatassembler.net/topic.php?t=78&postdays=0&postorder=asc&start=0 |
|||
13 Oct 2003, 04:56 |
|
BiDark 13 Oct 2003, 05:23
Normally, fasm will mark the data section that has no intialization as 'unintialized data' and set disk size to 0 (no wasted space!!!).
All you have to do is do not mix up the intialized and untialized in the same section and you are done (the order doesn't matter). See Fasmw source code for example. Code: section '.data' data readable writeable initdata dd 4 initagain dd 3 section '.udata' readable writeable udatahere dd ? wc WNDCLASSEX ? somevar rd 1 section '.text' code readable executable main: .... and '.udata' will have 0 in raw size. |
|||
13 Oct 2003, 05:23 |
|
Betov 13 Oct 2003, 06:25
Standart Sections = Good.
Merged Sections for size saving = Ridiculous, IMO. Betov. |
|||
13 Oct 2003, 06:25 |
|
pelaillo 13 Oct 2003, 08:23
[imo]
Standard sections is very comfortable during debugging and the code is well orgainzed. Keeping global variables to a minimum is a challenge that well worth the effort. Variables embedded in code diminishes the code readability and debugging and I don't see any advantages in doing it. [/imo] |
|||
13 Oct 2003, 08:23 |
|
JohnFound 13 Oct 2003, 09:08
Hi all.
Well, all you are right about initialized and notinitialized data. But let's see what we have in Fresh. 1. Functions libraries: for example strlib. It uses only 1 dword variable, but it must be global. There are 2 ways: Force users to put this variable in his data section, ot put this internal variable directly in the code and let the user only to use library. I think second approach will be more readable and structural. 2. Form files: Like MainWindow.asm: This kind of files contains mainly one procedure for form message handling. They don't need global variables at all, but only one dword variable to keep form handle. This variable at startup must be NULL, i.e. it is initialized. About form creation data, I am thinking to place it in the resource section. 3. Different custom components libraries, like form.asm. Absolutely the same, they does not use any global variables, but string constants that are read only. So, Fresh (and it the future - Fresh created programs) is highly modular and global variables are mainly for internal use from the separate modules. Why not to place these internal variables in the modules? This will make programs more structural. Of course normal data section for some variables not-related with some module and uninitialized variables and buffers, must stay. Let's open Fresh.asm and make some analisis what kind of data is in data section: 1. Strings with class names of standard windows classes. 2. Many variables for windows handles. They are here, because we need some var to remember the handle of the created windows. But the right place for this definitions is in the module of the window. hMainWindow, hMainToolbar etc. in MainWindow.asm; hSourceEditor, hTab, hStatus in the sourceeditor.asm. etc. etc. 3.... The most of these variables are initialized: They must be NULL at the startup, because we can determine, is the window created or still not. The most of initialized data: string buffers, arrays etc. can be defined as local variables in the procedures that using it. The main idea is to place all initialized data and small module related variables in the code section and to leave one data section for uninitialized data - arrays, buffers etc, where they can't be placed in the stack as local variables. Well, I will think more for these problems. Of course your opinions are very important. The main goal is to make everything highly modular, structural and readable. Regards. |
|||
13 Oct 2003, 09:08 |
|
decard 13 Oct 2003, 09:43
I still don't think mixing code and data (even initialized, even if it would be only "a little" pointer in each file, etc) isn't good. Maybe we could use some macroses? It would be a good compromice IMO.
Joshua: could you write some info on usage of your macroses? Maybe we could them, or we maybe write something new for that purpose? |
|||
13 Oct 2003, 09:43 |
|
Betov 13 Oct 2003, 14:28
John,
Point 1: You can declare this kind of Data with an friendly Macro doing the clean and standard Declaration job. Point2: Un-initialized Data _are_ zeored at Start-Up. Point3: Same as Point 1. (Read-Only not important). For your other comments, all i can say is that, when i will write the Wizards DLL for ReactOS, it will not be done this way... For the naming conflicts problem (i am not sure if you are targetting this with the solution you are thinking now...), i suppose FASM does have something like the Local Variables of RosAsm (The "@X" thingie... it seems to me to be a ".X" thingie in FASM syntax, if i recall), this may help a lot for "modularization" (whatever you and me call so... ). Betov. |
|||
13 Oct 2003, 14:28 |
|
JohnFound 13 Oct 2003, 15:46
Hi, decard, Betov.
Well you almost convince me. I am working on some macro solution now. I saw Joshua's macroses. They are good written and partially solve the problem, but actually I don't like them. They illustrate the FASM macro power, but they are too complex and the one must be macro wizard to understand what actually happen. I want to keep Fresh standard macro library as simple as possible. Don't forget that beginers will use Fresh too. (btw: I think the same for last Privalov's "struct" macro). Regards. |
|||
13 Oct 2003, 15:46 |
|
JohnFound 13 Oct 2003, 19:15
Well, I have some idea. It does not work, because of some problems, but it is very simple:
Code: GlobalCount = 0 struc RECT left, top, right, bottom { ; only for example using structures. .left dd left .top dd top .right dd right .bottom dd bottom } macro global { GlobalCount = GlobalCount + 1 macro _GlobalBlock { } endg fix } macro IncludeGlobals { _GlobalBlock purge _GlobalBlock } global var1 dw 1234h var2 dd $abcd endg global var3 dw 5678h endg global var8 RECT 1, 2, 3, 4 endg ; I can use every of the global variables and this code will be at the ; begining of the binary file: mov eax, [var8.left] mov esi, var8 ret ; Following is somewhere in the code, probably in data section. ; The problem is that there is imposible to make ; loops in preprocessor stage... ; So, for now this approach is unusable, bacause we can't ; determine how many times 'global' macro is used. IncludeGlobals IncludeGlobals IncludeGlobals |
|||
13 Oct 2003, 19:15 |
|
Tomasz Grysztar 13 Oct 2003, 19:32
My quick solution of your above problem:
Code: GlobalCount = 0 struc RECT left, top, right, bottom { ; only for example using structures. .left dd left .top dd top .right dd right .bottom dd bottom } macro global { IncludeAllGlobals fix IncludeAllGlobals, macro _GlobalBlock { } endg fix } macro IncludeGlobals dummy,[n] { forward _GlobalBlock purge _GlobalBlock } IncludeAllGlobals fix IncludeGlobals global var1 dw 1234h var2 dd $abcd endg global var3 dw 5678h endg global var8 RECT 1, 2, 3, 4 endg mov eax, [var8.left] mov esi, var8 ret IncludeAllGlobals |
|||
13 Oct 2003, 19:32 |
|
JohnFound 13 Oct 2003, 19:59
Privalov, of course you are macro wizard, but how the fuck this work:
Code: IncludeAllGlobals fix IncludeAllGlobals, |
|||
13 Oct 2003, 19:59 |
|
Tomasz Grysztar 13 Oct 2003, 20:07
It simply adds the comma to the value of "IncludeAllGlobals", so finally "IncludeAllGlobals" will be replaced with "IncludeGlobals" followed by the number of commas equal to the number of "global" structures you've defined. "IncludeGlobals" uses that count of parameters (all are empty, as there are commas only) to repeat its job appropriately.
|
|||
13 Oct 2003, 20:07 |
|
JohnFound 13 Oct 2003, 20:14
Thank's Privalov. I got the idea.
I think this will solve the problem, so I will make some macroses for handling global variables, uninitialized and initialized for Fresh. ...probably tomorow. Regards. |
|||
13 Oct 2003, 20:14 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.