Assembler Enhancement Initiative

[Serj]

Hi, guys. I wanna tell you about some of my thoughts about assemler.
So, I often use standalone assemblers to develope programs entirely in this beautifull language and several years of practice brought me to an idea of complete enchancement of assembler. Today we have three main chioces of how to develope a program:
- use standalone assembler.
- use Highlevel language such as VC++ etc.
- use HL and its built-in assembler.

Let's talk about the first way. Let's say honistly that assembler is very very inconvenient development instrument in comparison with HL compilers. There are some concrete problems:

- almost no support for creating and management of namespaces.
- week support for type checking
- week mechanisms for detecting errors at build-time
- week support for describing complex data and code structures

This problems make it almost impossible to develope large serious projects using assembler so tried to enchance it. I wrote a macrolibrary but discovered tons of bugs in MASM's  preprocessor so it's still just a project. I've considered closely almost all existing win32 assemblers and i'm absolutely sure we all need a new powerfull one that will make it so easy to develope applications that you will forget about all HLs)) I hope you aree with me. So, let's begin a serious discussion. I've got big experience and advanced ideas but i started this topic no to discuss them but just to see you are READY. Drop a line about what features do you think assembler needs, what other problerms do you see and may be something else. I really hope you all are enthusiastic and we will soon make this world bettrer)..

[ramguru]

I'm pretty satisfied with poasm or masm their suit my needs even for big projects. Assembler isn't meant to be clearly comprehensible, it's for people who are not afraid to spend more time coding who are opened for challenge...and if you're not ready to accept one, better look at stuff that M$ is offering, like that VS2008 which is migrating to "speech to pe_coff" pattern

[hutch--]

Serj,

Welcome on board. You have some interesting ideas but I am not sure how you would put an assembler together to deal with the problems you see.

- almost no support for creating and management of namespaces.
- week support for type checking
- week mechanisms for detecting errors at build-time
- week support for describing complex data and code structures

In procedural programming "namespace" is more or less a "so what" consideration.
Type checking is as much a pain as an advantage but MASM can tighten that up if you want to write that style of code.
MASM manages build time assembler errors without much trouble.
Complex data structures are usually written as libraries and yes you can do them in assembler.

The preprocessor in MASM is old and quirky but it manages to do many useful things when macros are written properly.

One area that really could do with big improvements is a far more poweful pre-processor that can be done as a plugin to the assembler as it would allow the programmer to properly customise the pre-processor capacity.

[Serj]

I'll explain then my thoughts more carefully.

1) Namespaces - procedures can almost never be nested. What d'you think about nested procedures? I think it'd be an easy way to group code pieces that make similar job.
2)Type checking is a pain only when it requires casts too often. Actually casting can be hidden from programmist (when type sizes are equal and so on) and you will only need to use casting when it really helps avoid seriuos mistakes. But there's another application for type checking. Only by means of casting and type checking you can tell assembler, that some variable is not just a double word but it is a pointer to a quite complex structure.
3)I think most runtime errors are caused by using wrong values as pointers, so to catch such errors at build-time all working with pointers should be done in very very accurate manner. Actually there's a way to put working with pointers behind the scenes.
4)Well, and what will you do if you want to create several instances of that data structure? Will you try to load the library several times??)) MASM's structures dont provide means of discribing some kinds of complex data strutures, but let's discuss it more closely in future.
5)The only way to make the language's grammar very flexible and extensible is to use macros. It is part of my plan. I'll explain it when we will talk about compilation principles. I wanna object that in most complex cases macros written absolutely properly may produce errors. I've spent millions of hours trying to catch them but I give it up when I saw they are caused with internal bugs.

I'm glad to see there are some people at this forum that think like me)) I'm waiting for your new ideas and after some time when everybody who is really interested in what I suggest to do will say his word, we will start to discuss the subject more closely.

[Vortex]

Hi Serj,

I would like to introduce here a well known and  flexible method to build applications :

- use HL and object modules ( MS COFF or OMF ) created by assemblers.

You can easily create optimized routines in assembly where high execution speed is required. Those routines should be assembled to build libraries to support high-level languages. The flexibiliy of C / C++ and the power of assembly is a well know combination. As an example, I can mention about C start-up modules coded in asm to reduce the size of executables built with C compilers :

http://www.masm32.com/board/index.php?topic=166.0

Despite those problems you mentioned, Masm is a very powerfull assembler. You can even do OOP with Masm, ObjAsm32 is a good example :

http://objasm32.tripod.com

[Serj]

Vortex, I can't but to agree with you that C/C++ and assembler is a very good combination. But I'm talking about a bit another thing. You sad that C/C++ are flexible. Yes they are. They're far more flexible than assembler, so if you are interested in rapid development of your applications you have to write some code in C/C++/VC++ and other part in assembler so in fact you cannot just sit and code, you have to warry about HL support in your assembler code. But haven't you ever dreamed about such an assembler that could do all the work alone, providing C++'s flexibility and power.

I often met people that just hate HLs 'caz they produce horrible code for quite simple and handy HL constructiaons. But if you bring HL elements into assembler you have a chance to know what code that elements produce and make sure that code is quite optimized. I know almost all methods of building applications using assembler in combination with other instruments but dont' you want to make all programs with only one tool? I want! And guess you too.)) I just wanna stop this shit and make a really powerfull and flexible assembler so that people can use it without those problem they have to put up with today

P.S. Sorry, but OOP in MASM is just perversion.) This is my private opinion and I dont want to hurt anyone but beleave I know what I'm talking about.

[GregL]

Serj,

I don't know, but I just don't see all the problems with MASM that you do. Granted, there are cases where it's not the best tool to use, but you can do anything with it. It sounds like what you want is a high-level language. I am pretty satisfied with MASM as it is too. If I want all the stuff your talking about I'll use a high-level language. No offense, but that's how I feel about it.

[hutch--]

Serj,

I would have to agree with Greg here, while I understand your criticisms and have heard most of them before, to rectify these comments as problems would be to no longer end up with an assembler but a high level language. The rough distinction is between bottom up as with an assembler versus top down with a compiler that has an inline assembler built into it.

A large number of people who write assembler are also highly fluent in numerous compilers and have a pretty good idea of what does what so they tend to chose to use an assembler on a very well informed basis whether its for components (object modules) or for specialised small apps and/or DLLs for languages that cannot produce them properly.

The OOP view has its place in high level languages if you have the tolerance to suffer the design but it does not have a place built into an assembler as it would no longer be an assembler. Building OOP design with an assembler is a different matter and a number of people have done it in reliable ways but the day an asembler shifts from delivering a 1 to 1 correlation between written code and generated opcodes it becomes just another compiler.

Where I suggest there is room for smart enhancements is in the control of a pre-processor. The one in most C compilers is a pile of appalling toothless junk that MASM eats alive yet as I mentioned earlier, the pre-processor in MASM is quirky and old and you need to know a lot about it to get the more complex macros going properly.

Randy Hyde has taken a different approach, he uses an assembler as a back end and effectively produces a complex pre-processor for it with what he calls a high level assembler. Not all agree with him but its a similar idea to what you appear to have in mind.

[Shantanu Gadgil]

Serj,
...
... but you can do anything with it. ...

I have faced problems with nested structures and having predfined nested structures.

Some months back I was working with MASM and predefined nested structures thing and hit a wall with the way you can define them.
The same thing worked OK in POASM btw! :)

Later in the day I saw that, that is an inherent issue with MASM and there was nothing much I could about it!!! (Just use POASM, I guess)  :toothy

Given that this predefined nested structure thing  is a snap in C code it could very well have been possible in MASM!!!

Leaving aside the reasons of "why the feature is not implemented" etc, this is something I have faced issues with!

Regards,
Shantanu

[japheth]

> P.S. Sorry, but OOP in MASM is just perversion.) This is my private opinion and I dont want to hurt anyone but beleave I know what I'm talking about.

> The OOP view has its place in high level languages if you have the tolerance to suffer the design but it does not have a place built into an assembler as it would no longer be an assembler.

I have some doubts that you 2 know what you are talking about. Implementing some support for OOP in an assembler is the same thing than implementing the "LOCAL" or "PROC" directives, for example. And these directives are useful and don't make MASM a compiler.

[hutch--]

You are probably confusing the difference between a bare assembler and a macro assembler ratrher than the difference between an assembler and a compiler.

[Serj]

Well, guys, I think you don't get me absolutely right. I don't want to make a HL compiler. I think you just were misled with my statements about handy features HLs have. hutch--, 1 to 1 correlation is the basement of any assembler, it's the basement of my ideas too. When I talk about HL features I, actaully, dont mean they should be hardcoded in compiler. I think assembler should provide some basic way to describe code and data as it is, and most assemblers do it quite well, but a powerfull assembler should also provide a programmer with means to indroduce HL constructions that of course should be emplemented as macros. Hence, you have absolute control of abstraction level you work at: if you want to use bare assembler you use it, if you want to insert some ready code you use macros. But let's look at it from a bit another point of view. We can make an assembler that will provide bare coding mechanisms as well as a way to extend lang.'s grammar with macros, but not only extensions could be emplemented as macros, bare coding mechanisms can also be based on macros. Just imagine, you've just created a very cool assembler and the next day Intel releases a new processor with absolutely new architecture and of course new set of commands and ,in addition, Microsoft reports they already support it, so you're gonna rebuild your assembler to support new commands etc. But if all commands in your assembler are just macros you only need to correct them and add some new ones. So the only language assembler must support in this case is a macrolanguage, that provides some means to define code and data as it is, so it's not assembler which produces code but flexible macros that can be easily changed without changing assembler's code. What d'you think of it, hutch--? Ah!?

At last I want to show you a snippet that I was testing while working on the first version of my macrolibrary. I place code that was really assembled in comments. I don't wanna you think that I suggest to build an assembler with support of this macrolanguage, it was just a project and no more.

...

image  ; .code

    object main():default   ; $main:

    protobj first(int32 par1, int32 par2, int32 par3)

       mov eax,val(par1)   ; mov eax,dword ptr [ebp+8]
   
       ....

       first(1,2,3)   ; push 3/ push 2/ push 1/ call $main$first

        ....

        invoke ExitProcess,0

        object first(int32 par1, int32 par2, int32 par3)   ; $main$first:/ push ebp/ mov ebp,esp
           
        ...

            return 0   ; leave/ xor eax,eax/ ret 12

        endobj first

    endobj main

endim   ; end $main


I hope you won't say that I suggest to make a HL compiler instead of assembler any more))

[TNick]

You may do what you want, but if I will see a type checking in masm I will hang myself. LEAVE my DWORDS in peace!!!! :)

Nick

[Tedd]

Serj, I've had similar ideas to this so it is something I've also considered and thought about - I'll explain a few points and reasons why you will meet a lot of resistance trying to advertise this idea to a board of assembler programmers.

Firstly you should realise that HLLs and ASM are separated for a reason. ASM programmers like to know the lower-level details and see exactly what is going on, and control exactly what happens to each and every bit in the cpu. HLL programmers, on the other hand, generally want to ignore these details and get on with writing their code, allowing the compiler to take care of these tiny unimportant details (who cares what registers are used or how a function is called?) That said, many of us here can and do use both for different reasons and even mix the two together.
However, mixing the two immediately causes problems - there is a conflict between wanting to know all of the details (asm) and wanting to hide all of the details (hll.) This results in two types of tool: assemblers with a few extra lightweight HL 'features' (if-else, while-loops, basic structures, etc) and compilers that only really allow the basic insertion of asm code. Which is exactly what leads you (and I) to the idea that it would be very nice to mix the two and have an assembler which provides much better support for HL features, but without taking control away from the programmer. Unfortunately, you can only get so far with this idea without making it extremely awkward to use.
So, you take your plain assembler (supports instructions, symbols, etc - all the basic stuff you'd expect) and add on the expected if-else, while-loop, repeat, structures, unions, etc.. And that's very nice, but it doesn't offer anything over the competition. So you start to add in more useful higher-level things like classes and inheritence.. wow, it's really starting to get better now! All of this can actually be done quite nicely, and with little intrusion to the programmer (though it would be good for the programmer to read the manual so they can understand exactly how it works so they understand about providing the object pointers, which takes up a register.) And of course, now that you've got classes, you must have type-checking - the very point of having classes is to be able to build complex types - uh oh! This is where the conflicts begin.
Type-checking implies type conversion, and that implies inserting code without telling the programmer - unsurprisingly, asm programmers do not like this. In fact, even without this, asm programmers seem not to particularly like even basic type-checking "it's a dword!!" (masm does provide support for 'types' but very few use it - it causes more problems and actually leads to program errors because it sometimes alters the code you write without telling you.) Okay, a compromise, we'll have soft type-checking so it can be easily over-ridden when required, and any type conversions must be either an explicit cast (e.g. int -> dword) which doesn't generate extra code but is just sugar for the compiler, or a true conversion (e.g. float -> int) which obviously must generate extra code and must therefore be an explicit function call (which could be inlined.) There, that sounds a lot better.
Okay, this is really good - more! Well, it's really tedious to have to write out all of the instructions for a simple little expression like "a+b*c/d" so why not just write it like that and have the code generated for you? That sounds very nice, but it would need extra registers for the calculations and I might already have values in those registers. Okay, we'll save all registers used. That's pretty inefficient though, if we don't really need to save half of them. Okay, you can specify which registers to preserve - better? Well, maybe, although it's going to look a bit of a mess with all of these preservation enclosures, and type conversions and whatnot all over the place... This is why it's awkward - to take the features you must lose some control, or end up with some terrible syntax where you must specify constraints that turns out worse than just writing the code yourself.
And so it continues... You can add lots of wonderful time-saving features, making the asm code look more and more like hll code, but as you do you will need to take more and more control away from the asm programmer and generate code that wasn't explicitly requested. This is exactly the reason why many of us like to program in asm - it gives you that explicit control and you don't have a compiler meddling around with your code.

Now, as I said, I do (surprsingly) think this is a good idea. But it must be done in a particular way, for the reasons which (I hope) I've highlighted. And if you're wanting to pitch it as an assembler with HL features, then it must be exactly that and any design decisions must favour the asm side rather than the HLL. That means not hiding anything from the programmer - no implicit code generation, no hidden type casting or conversions, no runtime pointer checking, no compiler telling you that's not allowed or 'fixing' your code, etc. But these things are exactly what make hll features so 'nice' and easy to use - so you must choose which side to lean towards.

From your comments it seems you are more of a HLL programmer who likes to use ASM sometimes. But in order to make this project work you really need to think like an asm programmer - otherwise you will end up with a HLL compiler with some asm features - and that means using asm as a preference for a long time (I'm not saying this in any snobbish way, it's simply that asm programmers generally think in a particular way, and hll programmers generally think in another.) Also from your comments it seems you have not used masm for very long, many of the 'deficiencies' you point out are actually fully supported features - you just don't know how to use them. Also, suggesting that if you cannot find the problems with your macros then it must be caused by internal bugs strikes me as somewhat arrogant; not that I'm saying masm is in any way perfect, you may even be correct, but you are not an masm expert so the problems could be entirely yours - have you asked for help here?

Many program errors are caused by bad use of pointers - you are correct - this is true for HLLs, not so much in asm. The reason is very simply down to the information hiding that characterises HLLs. In asm you know exactly what a pointer is and what it's doing, in a HLL it can be many things depending on the type of the pointer and such. It's not pointers that cause the problems, per se, it's the fact that the programmers using them often do not know the implications of using them and what happens - because this information is mostly hidden from them. Of course they can, amongst other things, cause genuine mistakes for both asm and hll programmers, but asm programmers have the explicit details staring them in the face, and so are more likely to take notice and be careful, whereas hll programmers have a compiler to protect them and sometimes rely on it even when they shouldn't.


ADDENDUM:
I think this highlights my points quite succinctly:

You may do what you want, but if I will see a type checking in masm I will hang myself. LEAVE my DWORDS in peace!!!! :)

[hutch--]

Serj,

Perhaps you have not looked at masm lately after various people have done some work in masm's ancient cranky old pre-processor. The MASM32 project has been developing masm macros for years and you can have a good look at them in the last release of the masm32 project. (version 9). The macro file is macros.asm in the macros directory and the4e is a "high level help" help file for them.

Randy Hyde has taken the alternative approach and written his own pre-processor in his project HLA which has an extended capacity beyong the pre-processor in MASM.

Now another problem you will run into is the inbuilt prejdice of many older asm programmers to any form of high level construction. It has been the masm32 project that championed the built in pseudo high level constructions in masm.

If I get what you are sketching out, its a concept from the mainframe days which is a programmable assembler / compiler where the bulk of the work is done as macros. Its an interesting idea and vaguely I think there is still one made that way that exists but its not a common tool any longer.

The problem as I see it is the only interests your idea is serving so far is people who want a high level architecture and there is a simple answer for them, let them use compilers where they have all of the high level attributes. Mention "abstraction" in the C++/OOP/Delphi/VB/SmallTalk etc ..... and you will probably get a cool response from anyone who has escaped from this trash and can write assembler code where they want to.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

main proc

    LOCAL pbuf  :DWORD
    LOCAL buffer[260]:BYTE

    cast buffer, pbuf

    .if rv(GetCL,1,pbuf) != 1
      print "Please enter the name of an ALA programmer",13,10
      print "Your choices are : "
      print "Annie Beth Betov Frank Hutch Randy Wannabee",13,10
      return 0
    .endif

    switch$ pbuf
      case$ "Annie"
        print "Best uplift bra in ALA",13,10
      case$ "Beth"
        print "Programmer and social commentator extrordinaire",13,10
      case$ "Betov"
        print "Betov is a "
        REPEAT 8
          print "chick "
        ENDM
        print "chicken",13,10
      case$ "Frank"
        print "Nature's gentleman",13,10
      case$ "Hutch"
        print "Geriatric API Grinder",13,10
      case$ "Randy"
        print "Master of reality",13,10
      case$ "Wannabee"
        print "Howz the chewin' goin' Wannabee ?",13,10
      else$
        print "Sorry, I don't know that programmer",13,10
    endsw$

    return 0

main endp

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««