Re: To C.

From: C (blackmarlin_at_asean-mail.com)
Date: 06/15/04 

Date: 15 Jun 2004 06:59:35 -0700

"Beth" <BethStone21@hotmail.NOSPICEDHAM.com> wrote in message news:<vXuyc.731$KL6.346@newsfe5-win>...

['unified assembly' idea]

While I cannot say whether the idea of 'unified assembly' is
a good idea or not from the programmer's prespective, there
is some problems with the implementation side of it.
Specifically that sections must be identified as such due
to the way relocations work in most executable and object
formats. (We do not want to be hand coding relocations,
even with macros they would be _very_ difficult to do
efficiently, if at all.)

As a result, while your idea may well be worth pursuing at a
later date, doing so now would not be too useful. Probably
the best course of action would be to design Luxasm using
a common core and pluggable modules for the parser, opcode
generator and file encoding (which utilise common load/save
etc functions in the core) -- this would allowing one to
write a new parser which processes your proposed syntax
while still allowing more conventional forms of assembly to
be processed (using a different parser module) and minimising
the amount of code duplication (as the instruction generation
and file encoding modules would be shared).

I thought you where going to design such an interface to allow
dynamic module loading to a core IDE -- now would be a good
time to do so, well before that part of the project is under-
taken. Especially as faults in the design of the part of Luxasm
could prove very costly given that changes would be all but
impossible after coding begins there -- so getting it right is
a must.

(Note: the code I a currently writing for the Luxasm prototype
is _mainly_ to test the syntax and semantics (especially the
enhanced macro capabilities) plus to write an assembler implement
Luxasm proper, therefore throwing away that code does not bother
me greatly -- but I expect most of it will be useful in the final
product anyway.)

[luxasm addressing modes]

Oh, and by the way, the current design of Luxasm _does_ have some
complex (HLL style) assessing mode -- you can do...

        #type ebx, MyStruct
        mov eax, ebx->struct_member

Which would be interpreted as...

        mov eax, [ ebx + MyStruct.struct_member ]

(Of course this assumes the label 'MyStruct.struct_member' has
been definied somewhere, otherwise a 'label not found' error
would occur.) This is about the only internal use Luxasm makes
of its type system -- any further use is controlled via macros.
While this is not very useful in itself, it does allow complex
macros to be written which make use of these features, ie. the
following example would be possible, given the correct macros.

        procedure a_proc, param_1 : qword, param_2 : dword
                mov eax, esp->param_1[ 0 ]
                mov edx, esp->param_1[ 4 ]
                call a_proc_2, esp->param_2:4, esp->param_2:4
        end_procedure

This would be interpreted as...

        a_proc: mov eax, [ esp + a_proc.param_1 ][ 0 ]
                mov edx, [ esp + a_proc.param_1 ][ 4 ]
                push [ esp + a_proc.param_2 ]:4
                push [ esp + a_proc.param_2 ]:4
                call a_proc_2
                add esp, 8
                ret

And with a_proc.param_1 defined to '4 + __STACKP', using the
macro...

        #macro procedure
        # assign ##p, ##1
        # type esp, ##1
        # equate ##l, 4
        # delete __STACKP
        # while ##0 > 1
        # shift 1
        # assign #( ##p "." ##1 )#, ##l + __STACKP
        # equate ##l, ##l + #( #type ##1 ".__size" )#
        # end#while
        # equate __STACKP, 0
        #end#macro

        dword.__size = 4
        qword.__size = 8

[Hmm, the hashes _are_ a bit distracting -- maybe using '?'
would work instead of '##' to identify macro labels.]

'__STACKP' is a stack position indicator which is modified on
push/pop stack modification instructions, therefore you have
automated stack management all in macros -- from there is a
only a short step to add automated stack alignment and name
mangling, features which would improve execution speed and
reduce errors respectively.

Finally the code would become...

        a_proc: mov eax, [ esp + 4 + 0 + 0 ]
                mov edx, [ esp + 4 + 0 + 4 ]
                push [ esp + 12 + 0 ]:4
                push [ esp + 12 + 4 ]:4
                call a_proc_2
                add esp, 8
                ret

[90% of this can be achieved with NASM macros, though the syntax
is a little more constrained, due a NASM lacking some of Luxasm's
planned features.]

C
2004-06-15

Loading