Re: ///Wannabee Rants


//\o//\annabee <Free wrote:
På Tue, 09 Jan 2007 01:35:03 +0100, skrev sevag.krikorian@xxxxxxxxx
<sevag.krikorian@xxxxxxxxx>:


For me, it's about 90/10 HLA/FASM. FASM still lacks type-checking
facilities.

Why are theese so important?

I use them in my programming.

As for RosAsm, as soon as the macros system is improved
with type checking for user defined types and it can generate object
code, I'll give it a serious spin.

How could type-checking make any sense in asm?

Type checking has nothing to do with asm. It has nothing to do with C,
Pascal, Delphi, etc. etc. Type checking is data representation and it
has everything to do with *programming.* Some tools offer it, some
don't. I prefer the ones that do.


mov edi D$esi + Objects.Current

In this case I know that "Object.Current" is an equate, pointing at a
Paragraph object, or an object part of the "tree" that Paragraph object
belongs too.

It close to impossible for me to try to parse a list containing objects
not allready compatible, unless I make an error. So therefore, in the
event I could make a bug that cases ESI to point at some villain memory,
how could type-checking be of any use?

Suppose ESI was written by a bug, like this : "pop esi", how could RosAsm
detect that the correct type has present in the stack, at compiletime?

?

I do not understand this type-cheching thing, or why and how it could be
any advantage in asm.


Type checking has uses in any programming language. Of particular
interest in assembly is when combined with a capable macros system.
Maybe you would never use such a thing, but imagine a macro that
generates code based on the *type* of data passed to it.

macro_Foo ( myLabel1 )
#if ( @type (myLabel1 ) = "dword" )
; write some code
#elseif ( @type ( myLabel1 ) = "tBuffer_Class" )
; write some other code
#elseif ...
; ...
#else
#error ("Unknown type passed to macro_Foo")
#endif

When using registers as pointers to data, then you would have to inform
the compiler what kind of data is in the register (unless it's just
plain dword).

macro_Foo ( (type tBuffer_Class [eax]) )

or if you prefer
macro_Foo ( tBuffer_Class$[eax] )


In addition, if i make a procedure :

Proc SaveObject:
Argument @BaseObject
mov edi D@BaseObject
BaseObject.vCall vSaveObject
EndP

And if I then called it like this:

push edi | call SaveObject

and edi was (because of a bug) containing a perverted pointer, maybe the
bug was done a lot earlier.

How could RosAsm detect this ?

It can't. Not even HLA type checking can detect this. If you want to
take advantage of type checking, you have to use higher level functions
(like macros).

For the above, you would first need a "Proc" macro that can determine
what types of data to accept. In Rosasm case, It's practically already
in the syntax, all you would need is for the macro system to recognize
"Argument" items as types that you have declared elsewhere:
It would be roughly:

[@BaseObject 4] ; define "BaseObject" as type with 4 bytes

[myClassPtr @BaseObject] ; reserve 4 bytes for myClassPtr as
"BaseObject"

Proc SaveObject:
Argument @BaseObject ; declare parameter 1 as type "BaseObject"
mov edi D@BaseObject
BaseObject.vCall vSaveObject
EndP

invoke SaveObject, myClassPtr

Now if you passed the wrong pointer type, the macros processor would
know and give an error. But this is a simple use of type checking. A
more significant use, as demonstrated earlier is when a macro can do
various things according to the type of data passed to it. For
example, my "buffer" class can accept input data from many different
pointers: signed/unsigned 8/16/32/64/128 (converted to ascii), char,
all standard types (as data bytes), strings, streams of data with
address offsets, another buffer class, etc.

It has 2 general macros for accessing:

tBuffer.append ( <list of args> ) // append data at end of buffer
tBuffer.insert (<list of args> ) // insert data at current cursor
position

It will scan all the argument *types* and determine the appropriate
function to call. You can forgo the macros and call the individual
functions, but it quickly becomes a pain and that would defeat the
purpose of having tBuffer as a class.


The bottom line is that it's possible you never use type checking and
perhaps never
have any need for it. But...

Now for a bit of rationality:

For me, the only assembly language that has everything *I* need in one
package is HLA. And apparently Rosasm has everything *you* need in one
package. So...

Would it be fair to say everyone has different needs?

Would it be fair to say HLA is the perfect assembler for me while
Rosasm is the perfect assembler for you?
[and please don't turn this into another discussion of what is or is
not an assembler, I've heard all the arguments and I don't buy them]

-sevag.k
www.geocities.com/kahlinor

.

Relevant Pages

  • Re: "We Never Use Assembly Language"
    ... too bad that I expect the same from macros that I use. ... I guess Rosasm is no longer written in assembly. ... does not detract from a tool being an assembler. ... it raises HLA some levels. ...
    (alt.lang.asm)
  • Re: "We Never Use Assembly Language"
    ... > too bad that I expect the same from macros that I use. ... Are you unable to see the diffrence?The rosasm macros are little else but clever text replacesments for asm instructions. ... but it has nothing todo inside an assembler. ... well feature for feature to the Rosasm IDE which took near a decade. ...
    (alt.lang.asm)
  • Re: "We Never Use Assembly Language"
    ... too bad that I expect the same from macros that I use. ... I guess Rosasm is no longer written in assembly. ... but it has nothing todo inside an assembler. ... Not an assembler feature [naaf] ...
    (alt.lang.asm)
  • Re: "We Never Use Assembly Language"
    ... You can easily create such macros in RosAsm. ... A "strong" and "powerful" macro parser, the way you think, is easy to implement, but it has nothing todo inside an assembler. ... doing HLA is what you want, then HLA is your only option. ...
    (alt.lang.asm)
  • Re: RosAsm Just Cant Compete with MASM (this is news?)
    ... RosAsm couldn't do this. ... >> created to extend the capabilities of INVOKE. ... > very simple and very evident reason, that MASM Macros ... an assembler is a compiler for an assembly language. ...
    (alt.lang.asm)