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:

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.

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

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.

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.

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.

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

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

Source level libraries can be considered also static libraries, in contrast to dynamic ones that are linked at runtime.

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.

Regards.

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.

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.

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.

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.

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.

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

sincerely,
is me vbVeryBeginner d(0)(^)b

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!

[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 ?!

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