I am very much a code reuse person for the obvious reason that I hate writing the same code over and over again. You can store bits of code in other files and paste them in when needed, you can include files into your code if it helps to keep large blocks of complex code out of your logic code but the bottom line is if a language cannot build blocks of binary code that can be reused, its still in the novelty range, Libraries are one of the great leaps forward in creating programs of any reasonable size.

Bogdans case is an unusual one in that he is building a complete game from scratch and there would not be that much code available for it. Trivial things like numerical conversions, parsing routines, search algorithms, display functions and the like are not things that you need to keep recreating, it just makes your coding slow and unreliable if you dont construct building blocks to make bigger things with.

The notions of scope being bandied around here are unusual, I see no reason why an assembler should aviod things like scope control, MASM has had this for years and if you need the capacity, its there to use. If assembler was restricted to a global bag of binary, it would have died out years ago. You can write assembler that way but it is rarely ever done and only on very small programs and it does not work any better or build any smaller.

High level concepts like code reuse, LOCAL variables, true modularity in libraries are the things that make a modern assembler very powerful and extendable to the extent of being able to compete within a timeframe that can be acheived, going backwards is a formula to send assembler to the scrap heap.

For Kenny, you have no alternative but to learn how assembler hangs together and if you want to build a piece of assembler that is generated by a C compiler, you will need to understand how it works in MASM. get the form of startup code from the existing range of MASM code, produce the include files that you need for the API calls and make it compatible with MASM and you should be able to build it.

Pursuing simpicity will not help you here, you have chosen to ry and use generated assembler, not written assembler so you have to learn how to convert it.

Regards,

hutch@pbq.com.au
Posted on 2001-08-04 21:29:02 by hutch--
Bogdan, I don't want to have a war against you... but I don't think
you're right. Sure, every man has his own opinions and all, so don't
tell me I'm wrong... I have quite a couple years of experience, at
least enough to know what I'm talking about.

If you think copy&paste is what I talk about when saying reusable
code, please think again. This is probably the worst form...


BTW. i just wonder why any beginner and C oriented programmer
are so much intrested into less typeing?


Not only beginners, also pros. And why? Because if it is done *right*,
it can save you so much time... WITHOUT being a bad and limiting
thing. But I don't suppose you know anything about this?


Because of "organization" we have a lots of "modular" files into
diffrent folders. Each file does specific actions and deals with
diffrent parts of our application....I thought its a good ideea at
the moment (somehow i still belive it is...damn me )


If you can't keep head or tails of your different modules, you obviously
did something wrong at some stage. Did you do any pre-design
before you started hacking away?


Now it is very hard to find one procedure in so many files and it
takes us some time until we find ALL links between diffrent
modules both physical and (worst) logical...


Well, the whole idea of modularisation is to keep the links *FEW*.
Too keep as much code/data local as possible... otherwise there
aren't many reasons to modularise, considering the fast hard drives
and processors these days...


So you see Modularization, encapsulation, code reuse and this
stuff are not necesary good....strange enough this is true esp for
huge applications


Sure, a hammer can also be bad if you don't know how to use it
correctly... you might end hammering your fingers...


There is a PROC at the hardware processor level: CALL/RET and
Stack mechanism (they added ENTER and LEAVE there lately)


PROC is not at hardware level. DUH there is call and ret.. but this
still does not handle stack automation at ALL.


Once again i have to point it out that helpers like
LOCALS. .IF .WHILE and such are a big problem for beginners andget them confused...


They actually make life easier. A bit too easy sometimes. So easy
that people don't know wtf is going on behind their backs.


Kenny, you really DO need to understand locals. They aren't all
that hard, and they are VERY important when dealing with multiple
threads et al.
Posted on 2001-08-04 22:40:52 by f0dder
Fodder, any link to some consistant Application that you wrote
in Assembly with a programmers'group? What kind of Application?

Do you mostly build the same kind of Application? (i mean, for
example, do you write games mostly, or dBases for clients?).


Betov.
Posted on 2001-08-05 03:13:41 by Betov
My problem here is not really to know if Modular programming is good
or bad. I begun programming in 1968 and have written enough Asm things
before SpAsm to be fully convinced that Modular programming is nothing
but the wide open door to make Asm as bad as C is.

A difficulty in this thread is that we are debating two things at a
time: The modularity in user source(s) management and the containement
of code with the symbols scope concept (and these two are not necessary
bounded to each other).

My problem, as an Assembler author, is that i have both to satisfy
users wishes and to maintain some consistancy in the overall design,
while i mean to push my "Specific Programming style" concept.


For the point of Containement (i mean, for example, what Fodder said
about a chunk of code being turned unable to call some 'private'
routine of another chunk), as i do not see any reason for doing this,
i will certainaly never make it possible.

Now, for the Sources management, and for the possibility of reusing
previously written routines, though i consider it bad as a whoole,
i *do* have to make it possible because this is on the user choice.

There are several ways for this. One way is what i did in the
Menu option: It opens a Dialog where the user have access to various
Snipets. Once choosen, the Snippet is in the ClipBoard, ready to be
pasted in the source. At my opinion, this is elegant solution because
the user *sees* what he is doing, he can modify and adapt to actual
specific requirements what he has just pasted.

I have some plan to implement an additional feature that would allow
the user to have his own Snippets collection in an external file, that
would be added to the Dialog internal Snippets Data. May be, putting
it all external would be better...

Now, i would like some answer, from a Modules_concept_defender about
my ante-previous post (about the "pseudo-include" thing, making chunks
of source appear as as many different files managed a Tab Control).
Would this be a practice solution? I wish opinions on this point
because the implementation of this feature raises very difficult
design problems that i do not wish to solve for nope (for example, the
Tab Data must be "Tree organised" in order to hold cases like 1000 of
different Pseudo-files... a killing problem).


Betov.
Posted on 2001-08-05 04:47:18 by Betov
First Betov,
============

i still dont think a unique big file is useable for a huge app like HE game....

include files are a usefull tool even with all its problems ... not haveing this in your assembler will sure be a problem IMHO

But i agree about containment: ANY assembler that will restrict my freedom to call/jump to any code section i so like will go stright to my recycle bin .... where it deserves to be

Assembler is about full control and power, let HLL deal with containment encapsualtion and stuff, i will do those better with my own brain.



Then fodder,
==============

I also dont want to start a war against you here

and of course i am programming from the beginning just before Z80 and I8080 come into the market (from about 20years) and have done LOTS of programs using ASM, C, Pascal, FORTH, DBase, FoxPro VisualFoxpro, Visual C++, Basic, Prolog,LISP...

I wrote all kinds of applications from GAMES to DATABASES and RADAR simulators or SECURITY applications

I have my own software company, big companys from Romania use my database programs every day, lots of small ones also....etc etc

The huge ASM application we where talking about (HE game) is 300.000 lines of code...do you realize that? holding my heads and tails inside it its a breeze .... belive me we have modularized it the best way we could ...

you still dont get it that PROC is just a macro gizmo for CALL/RET and ENTER/LEAVE and this instructions do affect the STACK...no problem you will in time ...

Stack automation? you mean nameing labels for local variables...well this label management was the first job of the assembler compiler and will still be its job long time from now....

If you want less typeing into programming....well .... maybe you choosed the wrong job after all....

keep the links "few" in a 300k lines program? maybe in a little proggy that does allmost nothing...maybe

I guess i know to use the "hammer" and the "needle" never damaged my fingers until now ;)

LOCALS are very simple to explain:

They are variables keept on STACK for just as long the procedure is running (until the RET or LEAVE instructions that is)

This is done by adjusting (substracting) the Stack ESP pointer with the size of ALL local vars...the base for local vars is saved in EBP register for easy acces (usually)

so all subsequent PUSH/ POP or other Stack management is done "under" your local variables and do not modify them

using those local variables by names is rezolved by the assembler that replaces their names with the corect ESP based address like , etc

when the procedure terminates it restores the stack pointer to the correct value and so efectively will overwrite your locals if new operations are done on STACK from now on....

i might say this way of working with procedures was my first thing i have learned from my ASM teacher (long time ago) using M80 one of the first Microsoft Macro Assemblers
Posted on 2001-08-05 11:29:53 by BogdanOntanu
Betov, I was once implementing a 32bit debugger for a custom dos extender
a while back. The debugger is lot now though :(, so is the extender.
None of the source was ever released, and the project didn't have
a name. I still curse at microsoft for writing such a buggy "OS" (dos).
Hard drive crashes suck.
I have also helped with bits and pieces of Qlib, a nice environment
for developing 32bit dos applications. I didn't play a very big part
there, though. Yes, this was all asm.

Currently, I'm implementing a toy OS kernel.
And this is a place where modularity and containment (imho) is important.
I want the VMM to be a subsystem of its own, process management
to be a subsystem of its own, etc. The less inter-module links there
are, the easier will the kernel be to manage, and the easier can I
change the internals of one subsystem without having to change
hundreds of other locations.

As for the rest of my programming project, this is mostly C code.
The commercial projects I work on at the moment don't have a need
for asm. There aren't really any speed critical parts. One of the applications
has a lot of complicated "engineering-style" math, but I'm not working
on that part of the program. And rewriting the math to asm would
be a VERY demanding task, especially since the engineers constantly
make little tweaks and whatnot to the formulas. And they aren't
really time sensitive, either. They're already about a thousand times
(or more) faster than the engineers sitting with calculators, pen
and paper... which is what they did before our app was developed.


Bogdan... I was a bit annoyed (for various reasons) when I wrote
the the last post, so I sounded a bit more harsh than I intended.
I don't really have anything to add, except that I very well know what
proc does and how locals work...
Posted on 2001-08-05 12:37:41 by f0dder
Kenny:

First, asm sources from M$ C compiler don't contain the necessary 'includelib' lines. Either update the output code (using hutchs-- function to lib tool, for example), or add the libs from the VS configuration dialog (linker tab) to the commandline (see example below).

Second, you need to include a defaultlib switch, for the C library crap.

Third, I don't own the DirectX SDK, so I couldn't link it successfully. It's your job.

Ex. (from compile.bat)

link -subsystem:windows -defaultlib:libc.lib -libpath:d:\vs98\vc98\lib -libpath:d:\vs98\vc98\mfc\lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib vertices.obj

Note that DX8 libs are missing here.
Hopefully this works...
Posted on 2001-08-05 17:47:34 by -SMK-
Try that in a sec, but I want to offer some advice.

Bogdan, instead of C&P, why not just define your re-usable code as a macro? That's what I used to do when I was programming in SpAsm.



Then everytime I wanted to mov eax, ebx I would just type myreusablecode instead.

I forget the code in MASM, but it's something like:
myreusablecode MACRO
mov eax, ebx
myreusablecode ENDM

in C++, I just use #define :)
Posted on 2001-08-05 19:08:57 by Kenny
YOU'RE A GENIUS! Man I don't know how to thank you!

I guess you could say that you solved about 10 of my problems that have been plaguing me the last 6 months just with one message :)

:alright: :alright: :alright:

P.S. Was this common knowledge and I was just in the dark?
Posted on 2001-08-05 19:41:20 by Kenny
Wow , I've created a rather busy thread.


Anyway, I'm not against modulization, I just wish it was made easier to do. I'd break my program into files like:

main.asm <-WinMaim!!

file.asm <-file I/O

paint.asm <-screen Out, vid ops

And so on....

But it's a pain to use a global value/proc define in main.asm in file.asm. Or to call a proc defined in file.asm in main.asm.

Now I add in paint.asm, and pretty soon the maze of EXTREN and PUBLIC definition start to get a little confusing. EXTRENDEF? The MASM32 help file is of no help, it's short and cryptic. More of a definition than an explanation.

I've tried searching for clear explanations, but have found very little information. I've looked at several multi-file assembly sources, but have seen no consistent method of resolving extrenals.

Would it be good to put all my globals into a global stucture? Then I could declare the stucture PUBLIC?

hutch-- says it is easy "once you get use to it". Multi-file programming, weather it is assmebly or C++ or <lang>, its the hardest thing for me to get used to(learn). For some reason, the abstract idea that just because it is defined in another file, it is out of scope, I can grasp. The way to overcome it is the problem.
Posted on 2001-08-06 14:53:51 by ThoughtCriminal
CoffeeDrinker, I would have an include file per asm file that defines
the public function definitions. Which are probably easiest to get
working via the PROTO command in masm.
Posted on 2001-08-06 15:06:06 by f0dder
Yea, just include the file and call the procs or use the macros. Everything should be global if you use only one base file:

main.asm
-> includes paint.asm
-> includes files.asm
... ect...
Posted on 2001-08-06 15:16:02 by Kenny
I don't include the asm files. I include the .inc files, and assemble
the asm files separately, then link them all together. That's the way
*I* like it :). But do whatever suits you.
Posted on 2001-08-06 15:28:08 by f0dder
Just a simple quick answer ....

Kenny,
========
we dont use macros instead of C&P because the code in not EXACTLY the same, LOOKs somehow the same but is slightly diffrent every time...

Using Parameters is just to slow ;) because this code is important: either AI for thousands of units, or BLIT routines, or unit's data access routines

Besides Macros MUST be placed in front on the include files...and this annoyes me and makes them harder to find in the big code..

But we use macros and parameters to ease our task from time to time...

F0dder,
=========
Sorry man i also did not wanted to be or sound harsh either ....

Please excuse.

we dont use the "link many object files" method because we still want to be able to search in the big .LST files all appearances of a function call or variable references

and we change many files many times anyway
Posted on 2001-08-06 20:26:40 by BogdanOntanu

Sorry man i also did not wanted to be or sound harsh either ....


bogdan, that's perfectly OK. Neither of us have english as our native
language, and I bet both of us have a LOT of things to look after,
and can be a "bit" stressed at times :). I don't know of a nice way,
either, to create a full listing when using separate object files. But
my experience is that the map files generated by the GNU linker is
better than the microsoft linker. Also, look for a product called "bugtrapper"
... it does a lot of nice things :).
Posted on 2001-08-06 20:43:36 by f0dder