Re: ///Wannabee Rants

//\\o//\\annabee <Free" wrote:

Why are theese so important?

I use them in my programming.

For what purpose? To do what? What is the advantage? The logic reasoning.

Something tells me you don't read the entire post before inserting your
respond-points. Otherwise you would have known that I explain why I
find them important in the rest of my post.

I show one useful example here:

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


This can also be done with RosAsm macro system, checking for sizes of
labels. and registers as well, I belive. Not that I could ever imagine any
need for it.

No, Rosasm can't do anything close to this. I can define *any* type in
my program (note "tBuffer_Class" above and have HLA distinguish between
every one of them without breaking a sweat. In comparison, Rosasm only
has a few native size-types, but no feature for user defined types. If
you recall, I specifically specified "user defined types" as an
important feature.


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] )


Still it will not protect from a perverted register, so what is its
advantage that warrant all this code mess ?

I did say it won't catch bad pointers in registers. This kind of thing
is called type coersion. If you want to know more about that, look it
up.

Your code is very much more
verbose, killing readablity.

No more verbose than using a Proc macro.

This is imho like having a cloud around you
head when coding.

Actually, once type-checking is in place, it makes code much easier to
read and maintain by anyone.


This isnt RosAsm valid syntax. Actually crash RosAsm. And such a simple
syntax...

Of course not, Rosasm can't do type-checking. I gave a quick
hypothetical sample of how it might look if such a feature was
implemented in Rosasm.


Very brutal and very plain facts. Should imo been
forbidden in programming. This is nothing but reinventing spagetticode.
Look at my plain asm code. It is tons better from all points of view.

No relation to spaghetti code at all.


To do what. You havent told us what it can do. In addition to
distinguishing types. Distinguishing types is easily done with a
calltable, the way I described in my post to betov. Thats what objects are
for.

You mean at run-time? That's kind of expensive.


This is by default done. It takes an object. Only if if you pass it a
perverted pointer will it fail. And typechecking cant guard againts this.
You said so yourself.

Are you actually reading this? You can pass it a pointer variable and
type-checking can detect wrong pointer variables. If you want to pass
a register, you have to coerce it which means you are being doubly sure
of what you are passing and what you should be passing. Any causal
reader can immediately know what goes where.


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"

This isnt RosAsm valid syntax. Actually crash RosAsm. And such a simple
syntax...

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.

So this is a compiletime feature trying to prevent a sleepy programmer
from making a bug?

It is a compile time feature, and one of the uses is to prevent sleepy
programmer bugs. If you think this is the only reason, you haven't
been reading with comprehension.
As I point out right after:

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.

What we have objects for.

That's not what objects are for.

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.

Some of this is also possible with RosAsm macros. but what is a typical
use?

Funny, you ask this question and following right after, I give you a
typical use:

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.

I cant see why. Is this extendable to userdefined types?

Bingo!

Scanning all those types could take lots of time in a large project.
Thats why OOA was invented, to do this directly via calltable.

Wow, you mean if will add a couple milliseconds to compile time? News
Flash, 'bee. Doing all that checking using rtti (run-time type
information) table *will* take lots of time at run time! I'd much
rather spend a less than half a second doing all this once during
compile time.


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

But what?

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

Thats not possible to know until we know what each offer.

I can't speak for you, but I know what HLA offers and what Rosasm
lacks. You seem to claim that Rosasm is the best thing you ever seen,
I can only assume it offers what you need.


Would it be fair to say everyone has different needs?

In order to determine what?

In order to determine which tools are best for which person.

Would it be fair to say HLA is the perfect assembler for me while
Rosasm is the perfect assembler for you?

Yes. But it would not make for much of a logical resonnement.

I don't see how much more logical you can get:
It has the features you want: you use it.
It lacks the features you what: you reject it.

Simple really. I've already told you what features need to be added to
Rosasm for me to give it a serious consideration.

[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]

fair enough. This has been debated to death. Thats exactly why I try
another angle. I am trying to understand the _advantage_ of type checking,
in order to understand why it is important enough for you to require it by
an assembler.

What I have understood now, by master PDFs and your posts, is that it is
for catching mistyping bugs. And maybe also a primitive form of OOA that
does not scale.

You partly understood, so it wasn't a total waste.

1. catch type errors
2. make better readability
3. easier maintainability
4. assist in compile-time code generation branching

It only takes one of these advantages to make type checking worthwhile.


-sevag.k
www.geocities.com/kahlinor

.