Re: ///Wannabee Rants

På Tue, 09 Jan 2007 03:19:47 +0100, skrev sevag.krikorian@xxxxxxxxx <sevag.krikorian@xxxxxxxxx>:


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

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


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

And why is that?



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

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.

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 ? Your code is very much more verbose, killing readablity. This is imho like having a cloud around you head when coding. 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.

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

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.

For the above, you would first need a "Proc" macro that can determine
what types of data to accept.

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.

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?

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.

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?

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?
Scanning all those types could take lots of time in a large project.
Thats why OOA was invented, to do this directly via calltable.

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.

Would it be fair to say everyone has different needs?

In order to determine what?

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.

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


-sevag.k
www.geocities.com/kahlinor

.

Relevant Pages

  • Re: ///Wannabee Rants
    ... Type checking has uses in any programming language. ... Rosasm can't do anything close to this. ... but no feature for user defined types. ... Now if you passed the wrong pointer type, the macros processor would ...
    (alt.lang.asm)
  • Re: "We Never Use Assembly Language"
    ... Except they are ususally much easier to find with RosAsm, ... How are you going to advance the art of programming or the art of OS making, if no programmer gets their hands dirty with the real thing? ... > doesn't even have the competence to implement a decent undo feature. ... Why dont you help by reporting this bug, ...
    (alt.lang.asm)
  • Wannabe sure wants to be
    ... the assembler can't handle the source file. ... > was given by Guga back then that this was a very low priority bug. ... And RosAsm shouldn't handle this, ... > the absolute best programming environment available for win32. ...
    (alt.lang.asm)
  • Re: "We Never Use Assembly Language"
    ... then who wrote RosAsm? ... It is very very GOOD that the macros fail you this way, because they make you aware of this fact. ... They are not the end of assembly programming. ... But if you want to learn assembly programming, then you need an assembler. ...
    (alt.lang.asm)
  • Re: Python syntax in Lisp and Scheme
    ... might be a challenge without macros. ... "properties" are in Python, possibly they are built for exactly that. ... Discovered there was a bug in the generated code? ... probably never miss it during your programming. ...
    (comp.lang.lisp)