flat assembler
Message board for the users of flat assembler.

Index > Main > How to handle big assembly projects?

Author
Thread Post new topic Reply to topic
Foamplast



Joined: 07 May 2004
Posts: 36
Location: Saratov, Russia
Foamplast
Hello!

I'd like to receive suggestions about ways to handle big projects.

I know that historically first was raw programming (machine-code and later assembly programming), then HLA programming: procedural programming, modular programming, and then object-oriented.

I was not thinking about this while I was writing small and medium-size programs. But now, when a project can contain more than 20000 lines of code it becomes hard to handle names of variables and functions.

I know that I may split program in modules and name variables like this:
Code:
Parser_ErrorMessage_UnexpectedCharacter db "...", 0    

But using such long names seems to be unconvenient.

I know what the object-oriented programming in C++ is. I like it for the ability to make the program well-structured and make data well-hidden as a nested Russian doll. But I like assembly language for it's purity of the result.

So then, how very big assembly projects could be conveniently handled?

P.S. Sorry, I've made a mistake: One should read "HLL" instead of HLA in 3rd paragraph.


Last edited by Foamplast on 26 Sep 2004, 07:46; edited 1 time in total
Post 22 Sep 2004, 20:53
View user's profile Send private message Visit poster's website Reply with quote
Dragontamer



Joined: 24 Aug 2003
Posts: 84
Dragontamer
The Iglobal header should work for that specific code. You could declare global data using it.

However, I don't seem to have it with me, and my linux box for some reason won't let me open up .cab files from the Fresh project that contain that header.

Can someone else post that header for me Smile
Post 22 Sep 2004, 21:58
View user's profile Send private message Reply with quote
Chewy509



Joined: 19 Jun 2003
Posts: 297
Location: Bris-vegas, Australia
Chewy509
Foamplast wrote:

I know what the object-oriented programming in C++ is. I like it for the ability to make the program well-structured and make data well-hidden as a nested Russian doll. But I like assembly language for it's purity of the result.

So then, how very big assembly projects could be conveniently handled?


It is possible to do OOP in asm, with a few good macros and a good understanding of how OOP is implemented... (Hint: search the forums for "OOP").

One of the biggest problems with any large project (in any language) is the available namespace support, (in addition to all the other problems, such as team support, etc).

The way I tend to get around it, is to prefix the module name to the function, eg STR_Compare_String (which is in str.asm), or FAT16_Get_Next_Dir_Entry (which is fat16.asm), etc. Unless you've got two modules with the same name, this tends to work well. (I'm open to other suggestions on other ways of handling this).

As for the use of long names, I tend to prefer these as they tend to be more descriptive and don't exhaust the available namespace quickly... But that's a personal preference.
Post 22 Sep 2004, 23:22
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
1. Procedures: as far as possible, keep procedures self contained and with local variables and local labels, grouped in static libraries.

2. Data Structures: choose one data structure that better fits your project needs and code arround it (a vertebral column). All other data structures will support/complement it.

3. Globals:Try to keep global variables to a very minimum and only when really needed.
Post 23 Sep 2004, 12:59
View user's profile Send private message Yahoo Messenger Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
Foamplast wrote:
Hello!

I'd like to receive suggestions about ways to handle big projects.

I know that I may split program in modules and name variables like this:
Code:
Parser_ErrorMessage_UnexpectedCharacter db "...", 0    

But using such long names seems to be unconvenient.


Some people like long names, if you don´t :
1: take a look to other big projects writen in assembler like Fresh or Menuetos.
2: use local labels and structs:
Parser:
.errormessage:
3:use macros to emulate a multiple namespace (but i don´t know how to do it)
4: use a assembly language with multiple namespace
HLA: works like a preprocessor that outputs fasm(or others) source code, i haven't check it.
Octasm: only outputs .com files for DOS ,i'm working on it.

other?

5: and the most important:
write docs about your source.
Post 23 Sep 2004, 20:00
View user's profile Send private message Visit poster's website Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 318
Vortex
pelaillo wrote:
1. Procedures: as far as possible, keep procedures self contained and with local variables and local labels, grouped in static libraries.


...and what if one doesn't want to use static libraries since FASM supports direct PE output? Maybe, you can consider keeping your procedures in separate include files.

_________________
Code it... That's all...
Post 23 Sep 2004, 20:04
View user's profile Send private message Visit poster's website Reply with quote
fasm9



Joined: 19 Jun 2003
Posts: 439
fasm9
> ..structure..

IMHO, AISB, it's impossible.
Maybe future version of FASM can handle this. ;)

Try to Type "OOP assembly" in google.com, then you will find it all of the projects are out-dated.
Post 23 Sep 2004, 21:11
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Vortex wrote:
...and what if one doesn't want to use static libraries since FASM supports direct PE output? Maybe, you can consider keeping your procedures in separate include files.


Source level libraries can be considered also static libraries, in contrast to dynamic ones that are linked at runtime.
Post 23 Sep 2004, 23:14
View user's profile Send private message Yahoo Messenger Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
Who said that OOP is the only way of handling big projects? Actually it is one of the ways, but in the price of highly overbloated code. IMHO, procedural programming have the ability to handle big projects and the overbloat is not so big as in OOP programming.
Fresh IDE is created with idea to be used in big assembly projects. It is still far not perfect, but is one of the very few big assembly projects around, so you can take a look at its sources. Other big projects I know are: FASM itself in all its versions, MenuetOS, RosAsm - it is not FASM project of course, but it have some very advanced source navigating features - with more human-friendly user interface some of RosAsm ideas whould be great. Wink

Regards.
Post 24 Sep 2004, 00:31
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
OOP doesn't necessarily lead to overbloated code. Incompetent use of OOP easily does, though.
Post 24 Sep 2004, 07:36
View user's profile Send private message Visit poster's website Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3500
Location: Bulgaria
JohnFound
f0dder wrote:
OOP doesn't necessarily lead to overbloated code. Incompetent use of OOP easily does, though.


Yea, you are probably right - theoretically. But IMHO, the incompetent procedural code costs less than incompetent OO code. And IMHO, it is impossible to be created "big AND competent" project. When the code grows, it is simply imposible to write everything in the most optimal way. Or it will take up all life to create only one project. (this is true also for HLL languages, not only for assembler).

Regards.
Post 24 Sep 2004, 08:45
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
I would say that OO code is quite easy to write, although reading (someone else's) object code, especially without good explanation of object hierarchy, much harder.
Post 24 Sep 2004, 09:10
View user's profile Send private message Visit poster's website Reply with quote
Vortex



Joined: 17 Jun 2003
Posts: 318
Vortex
pelaillo wrote:
Source level libraries can be considered also static libraries, in contrast to dynamic ones that are linked at runtime.


A static library is a collection of assembled files, in other terms, object files while source level libraries have to be processed on every assembly-time. Static libraries by architecture they are very different from source level libraries, so they cannot be considered in the same group.

_________________
Code it... That's all...
Post 24 Sep 2004, 10:14
View user's profile Send private message Visit poster's website Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
Vortex, the form apparently is different but the escence remains the same.

The difference between them will be the same that the difference between the source and the object file produced. As we are talking about Fasm sources, there are practically no differences (semantically speaking)

I didn't pretend to classify them, I was talking about functionality and for me, working with source level libraries or linking object files is merely a matter of compliation time.
Post 24 Sep 2004, 18:29
View user's profile Send private message Yahoo Messenger Reply with quote
fasm9



Joined: 19 Jun 2003
Posts: 439
fasm9
to me, OOP is procedure. procedure is OOP.

or maybe to ASM. asm have no ability to classify between them(OOP, procedure).

or another real example, Linux's VFS is written in pure C just like linux kernel itself, and it is OOP.

who said OOP is only in c++ ? ;)

--
and less bloated and compile time in c.
Post 24 Sep 2004, 23:48
View user's profile Send private message Reply with quote
vbVeryBeginner



Joined: 15 Aug 2004
Posts: 884
Location: \\world\asia\malaysia
vbVeryBeginner
em,
i guess the most IMPORTANT thing when coding for a project, whether it is a small, medium or big project is name management. (variable, proc, macro, function and so on that require a name)

so, imagine like you are a manager of a company, 50 people are certaintly more easier to manage than 100 people. so the same logic applies to variable. 50 variable name is definately more easier to manage than 100 variable name.

so, my first idea is,
use variable as LESS as possible.

usually, verb, adjective and noun play an important role when naming object.

window_set_option
WindowSetOption
window_setOption
WINDOW_setOption
setOption_WINDOW

we will get always many type of variable / proc naming scheme, and so, the second idea is, we MUST follow our naming scheme from start to end of our project, otherwise, we would really get lost in the middle of code

sometime, we are attempted to use the short-cut like

wc WNDCLASSEX
msg MSG

but this actually lead to another problem coz they are not conforming to our naming rulez. because if we got hundreds of short-cut like this, our head would really feels the pain. totally unmanageble.

the third idea is,
if you cannot even manage a small project in a decent nice way, then. forget about the big project. you would certainly not be able to manage it. (but u may be able to complete it ~ manage and complete are two different things)

if you check the iczelion tutorial posted on my website, i actually change a lot of my naming scheme from tutorial one to now, tutorial 17. one of the scheme that i feel ok now is the message. all the jmp for message is prefix with wmCOMMAND:, wmDEFAULT:

the windows handle changes a lot from wHMain, hMain, hWindow to wndH (now).

i guess it is a learning process, to find a name that really make you feel easy Smile

sincerely,
is me vbVeryBeginner d(0)(^)b
Post 25 Sep 2004, 05:41
View user's profile Send private message Visit poster's website Reply with quote
Foamplast



Joined: 07 May 2004
Posts: 36
Location: Saratov, Russia
Foamplast
Hello All!

Thank you for these posts. This opinions are very valuable indeed. I have understood that I like the way with OOP macroses. Generally speaking, any other method of splitting program into pieces would be a degenerated (I mean particular) sort of OOP.

I think than the only problem in handling big projects is managing names of functions, variables and structures. The problem is to do naming to be easy and effective, to let the person "see" the code, understand it's purpose and relations. This is a human-related problem, not machine-related (processor has no meaning what code it executes: OOP, procedural or other code - they are the same when compiled). Thus different people may like different solutions and it is naturally that all of you like different ways of organizing programs.

As for me I understand the text better if all names are small and descriptive. Thus I don't like long names. I find it very useful that in OOP a programmer can use short names when working "inside" the current object.

Maybe I am repeating, but it is a matter of taste what names should be considered as "descriptive" and "easy understandable".

Thank you!
Post 26 Sep 2004, 08:04
View user's profile Send private message Visit poster's website Reply with quote
penang



Joined: 01 Oct 2004
Posts: 59
penang
[quote="Octavio"]

Octasm: only outputs .com files for DOS ,i'm working on it.

[/quote]



I know this is OT, but how's the OCTASM coming ?!
Post 13 Nov 2004, 06:55
View user's profile Send private message Reply with quote
Octavio



Joined: 21 Jun 2003
Posts: 366
Location: Spain
Octavio
penang wrote:
Octavio wrote:


Octasm: only outputs .com files for DOS ,i'm working on it.





I know this is OT, but how's the OCTASM coming ?!

Don´t understand well your question.If you want to download to test it, do
a google search or go to programmers heaven.
the recommanded forum for questions related to octasm is:
comp.lang.asm.x86
Post 13 Nov 2004, 13:13
View user's profile Send private message Visit poster's website 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-2020, Tomasz Grysztar.

Powered by rwasa.