flat assembler
Message board for the users of flat assembler.

flat assembler > IDE Development > What if the code section is writeable?

Author
Thread Post new topic Reply to topic
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
Hi all.
Thinking for global variables in Fresh project, I wonder, what is we make .code section to become "readable writeable executable", so every library will define it's own global variables in the same source file as code.
FASM compiler uses the same approach.

Any opinions?
Post 12 Oct 2003, 19:57
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1095
Location: Poland
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 Smile
Post 12 Oct 2003, 20:07
View user's profile Send private message Visit poster's website Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
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
Post 13 Oct 2003, 04:45
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Joshua



Joined: 12 Jul 2003
Posts: 56
Location: Belgium
Quote:

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

Quote:

3. IMO new section for unitialized data should be created - the executable should be smaller then.

Quote:

one .bss section last in the code with all uninitialised data ('it will reduce the size of the exe* on disk),


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
Post 13 Oct 2003, 04:56
View user's profile Send private message Reply with quote
BiDark



Joined: 22 Jun 2003
Posts: 110
Location: .th
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.
Post 13 Oct 2003, 05:23
View user's profile Send private message Reply with quote
Betov



Joined: 17 Jun 2003
Posts: 98
Standart Sections = Good.

Merged Sections for size saving = Ridiculous, IMO. Wink


Betov.
Post 13 Oct 2003, 06:25
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 865
Location: Colombia
[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]
Post 13 Oct 2003, 08:23
View user's profile Send private message Yahoo Messenger Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
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.
Post 13 Oct 2003, 09:08
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1095
Location: Poland
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?
Post 13 Oct 2003, 09:43
View user's profile Send private message Visit poster's website Reply with quote
Betov



Joined: 17 Jun 2003
Posts: 98
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... Wink

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


Betov.
Post 13 Oct 2003, 14:28
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
Hi, decard, Betov.
Well you almost convince me. Smile
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.
Post 13 Oct 2003, 15:46
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
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... Sad
; So, for now this approach is unusable, bacause we can't
; determine how many times 'global' macro is used.

IncludeGlobals
IncludeGlobals
IncludeGlobals
    
Post 13 Oct 2003, 19:15
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7190
Location: Kraków, Poland
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    
Post 13 Oct 2003, 19:32
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
Wink Privalov, of course you are macro wizard, but how the fuck this work: Confused Wink
Code:
IncludeAllGlobals fix IncludeAllGlobals,     
Post 13 Oct 2003, 19:59
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7190
Location: Kraków, Poland
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.
Post 13 Oct 2003, 20:07
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
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. Wink

Regards.
Post 13 Oct 2003, 20:14
View user's profile Send private message Visit poster's website ICQ Number 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-2019, Tomasz Grysztar.

Powered by rwasa.