Object-Oriented Asm?
6 messages in this thread
All of the assembler example source I've seen is organized so that code is
in one section (the first), initialized data is in another, and
uninitialized data areas (if any) are in the third. Is this purely a
matter of style, or are there overwhelming technical reasons in favor of
doing things this way?
For example, say I have a code fragment to handle stdout. It would open
Dos.Library and store the results of Output() into an uninitialized data
region. It would handle intelligently any errors. In pseduo-code it would
look like this:
if not defined [dos.library handle]
define it, open it, complain on failure, store it, and
push the close-library routine onto the cleanup stack
jmp 10$
DosName PSTRING 'Dos.Library'
DosHandle DS.L 1
CloseDos … ; Routine to close library
endif 10$:
if not defined [stdout handle]
jsr Output() and store handle
jmp 99$ stdout DS.L 1 99$ ; All done
This approach allows assembly include modules to have initialization and
termination code. Does it give the loader screaming fits? Does it result
in objects spread all over memory? Should I try it and find out myself the
hard way?
THol,
While your (pseudo) code is currently "legal", it is being discouraged
by CBM guidelines, as it is mixing both code and data in the code hunk.
While this is not currently a problem, if and when we get to a OS
environment with true MMU support, it is quite possible that code like that
will break, as the CODE hunks may be loaded into write-protected memory,
while DATA hunks will be fully writeable.
Now if you wrote the code in the same fashion, but inserted the proper
assembler "section" directives, it would be quite legal (the assembler and
linker would end up piecing things into their "natural" order, while your
source code will be organized on a more "local" basis for maintainability.
Such as:
section code
if not defined [dos.library handle]
define it, open it, complain on failure, etc. …
jmp foo
section data
DosName PSTRING 'Dos.Library'
DosHandle DS.L 1
section code
foo:
more code, etc.
I'm not sure I particularly like this style, although I can see that it
would have advantages at times. But it is legal, and keeps the modifiable
locations in the Hunk Types where they belong.
Hope this makes sense.
…BobR
White Wolf Productions
I'm amusing myself by writing a little utility simultaneously in Tim
Holloway's C++ and C.A.P.E. 2.5's Assembler. I'm impressed by the sheer
quantity of gruntwork Tim accomplishes in the constructors he provided. On
the other hand, I'm impressed by how straightforward a recursive algorithm
can be to implement when one is working directly with (sp). I think at the
end, both C++ and Assembler programmers will find the sources a bit
repellent.
As an interesting sidelight, Windows (2.0 and 3.0) are well-known for
having self-modifying code… the fastest way they could do things like
bit-blitting, was to have Windows create the blit code on the fly, in a
spare piece of memory, then jump to it to get the bits copied.
I wonder if there are speed gains to be made on the Amiga using similar
heroic techniques? Maybe that's what the Eurodemo kids are doing?
THol() { cout << "Sir, I exist." ;}
John,
Of course, when programming for that horrid, Intel-based environment,
one can't pay any attention to "rules" and expect to get any performance
out of the hardware. Of course, even breaking all rules didn't help
Microsoft get any semblance of performance out of Windows 3.0 <grin>
…BobR
White Wolf Productions