Okay,

I know what many of you are going to say so I'm ready for the flamethrower to be pointed at me :D


Lets start by saying that I'm not considering starting a new project that I won't finish (in the miriad of other projects I'm trying to finish). We all know my reputation already (Visual Assembler Master, VisualIDE -- which is not dead but slow moving) etc.

What if a new assembler was to be written that perhaps resembles MASM, or NASM. Cool, huh? Just kidding.

But lets say that it had some functionality for OOP. Here come the flames.

in practice, it just contains a syntax for making a hard task simpler.

For example (psuedo code),



...
Class MyClass
PROC MyClassProc1 Dword
End MyClass
...
PROC MyClassProc1, DWORD
mov eax, 1
END PROC

Or

...
Class MyClass
PROC MyClassProc1, DWORD
mov eax, 1
End MyClassProc1
End MyClass
...

or

...
Class MyBase
MyBaseProc1
End MyBase

Class MyClass : MyBase
MyClassProc1, DWORD
End MyClass
...

Equals

MyClass
MyBaseProc1
MyClassProc1

or

..
Class MyBase
MyBaseProc1
End MyBase

Class MyClass : MyBase
Overload MyBase.MyBaseProc1
MyClassProc1
End MyClass



Well, I think you get the idea. this can currently be achieved, but look at the hoops that we have to go through with the OOP.inc they did. This would have to produce much the same behind the scenes code but it would be much cleaner to work with.

Just an idea. What do you all think?


Thanks,
Shawn
Posted on 2001-10-02 16:52:43 by _Shawn
That could be done with some kind of preprocessor which translates the code before ML.EXE assembles it. I have actually thought of this too.
Posted on 2001-10-03 01:12:41 by gliptic
MASM already has a symbol pre-processor built in.

It's called the macro parser. Make it your friend!

I've yet to find a case where a macro cound not do what a pre-processor could.
Posted on 2001-10-03 07:00:38 by Ernie
I think the Macro language is so damn restricted. Yes, you can make almost anything but it will be very bad solutions sometimes.
Posted on 2001-10-03 07:06:04 by gliptic
This was actually the first draft idea of our OOP model..

I was gungho on doing just this, and making a Pre-Compiler, that would then blast off to ML.exe to finish the job. At the time i felt the same about macro's too. (I certainly didnt think at that time i could do what is now being done with them).

We eventually went with the Objects.inc format because this is not C++, this is MASM. Most people like the ability to have both FULL knowledge and control over everything that goes on. To have a pre-compiler to interperit class info, and then send this "temp.asm" file to ml.exe would hide what was actualy being compiled. Sure i could incorporate switches, but you still wont have full control.

Choosing to then use macro's, i tried to document the detail and extent of each MACRO in objects.inc, because i KNOW people wont use the model unless they are sure its overhead is acceptable. (OOP is a hard one to get assembly programmers to use ;) , so we wanted to make sure the job was done right, taking the concerns that others *most likely* would have.)

As well we wanted to keep it open source for others to learn, using Objects.inc this is more easily done (as there is not software overhead, just the real deal).

Well, I think you get the idea. this can currently be achieved, but look at the hoops that we have to go through with the OOP.inc they did.


Shawn,

I've been patiently waiting for feedback and concerns over our beta version. So far, japheth is the only person with good feedback given (And an update with his suggestions is comming ~ as soon as school leaves me alone). So other than the fact it uses macro's, what are the 'hoops' that bother you??

BTW: This is just a beta release. We only released it because we are both in university and the main 'tool' for editing class files will still take a month or so to finish (school permitting). This tool wont compile code, but help you write it, and organize your methods/variables into ez to use tree views etc. With a VB style edit window to edit each method's code. Since we are fairly sure the model wont change now, we thought we might as well introduce it for those who were waiting. And hopefully by the time our tool is released, people will have learned it, and will be ready for the short cuts to come :)

Schools always teach you the foundations before they teach you the short cuts, like math, you'll learn the definition of a derviative using limits, before you learn the short cuts ie) d/dx (x^2) = 2x.

Im my oppinion, its good to know how to manually edit classes (which is what people are doing now), but we DO intend the tool to assist you as much as possible. This means all the 'pre-released' tools i gave out are not the final product. I just ripped the code into separeate make-shift programs, to assist you as much as we can (since the REAL tool is still needs to be finished).


NaN
Posted on 2001-10-03 16:41:12 by NaN
I don't use HLA but I have seen it and I'm a little familiar with it's architecture. It produces MASM code that gets compiled by MASM. So even then, it's a type of pre-something-or-another. Not a bad idea. The syntax takes some getting used to which is why I stick with MASM but it certainly has potential.

I was just throwing out an idea. If I were to make an assembler, which I'm not, but if I were, I would problem add a few conveniences but everything has a tradeoff. Asm programmers being the control freaks we are, some tradeoff's aren't as easy to make.

Thanks,
Shawn
Posted on 2001-10-03 17:39:07 by _Shawn
Oh i hear you there... :)

Im not trying to sway any decision out of your proposal, per see. But I did want to set the air clear with the going OOP example model.

Even more so, i want to make it easier for the users to use and understand if i can.. so, if you dont mind me asking again, what is it that bothers you? Any feedback is welcome.

Lastly, I failed to point out, that Thomas had a good sugestion for the "tool" yet to be released. As well as providing our own editor, we also plan to support a fully documented .dll for the IDE builders out there to easily tap into to. This way OOP can be better suported in IDE's with out the headache of having to 'know' how to implement it in their code.

(but this is still months down the line)....

NaN
Posted on 2001-10-03 23:02:33 by NaN