I have been thinking that since I started developing application for the industry rather than working on hobby programs, I have literally stopped programming with Assembly. The only reason for this is the development time. Now what if we had a high level assembly and I don't mean like HLA and OO Assembly. I am not talking about architecture and etc. I mean somehow making the assembly language more useful and faster and easier to use. So say you could program like this:

EAX = EBX++
if (PointsToMemory(EAX) == FALSE){
  EAX = Pointer(EBX);
  Image = EAX.Image;
  EAX.SaveToFile(Contentsof(ECX));
}

I think you get the point. Somehow a mixture of an advance preprocessor + a high level framework + Object Oriented Programming.

So basically instead of doing all Includes and etc and seeing what header files you have to include, you should leave that to the preprocessor. The preprocessor will take care of the includes. In this age, I don't think it is reasonable for a developer to worry about includes and etc. I am sure there is a better way of doing these small things which cause a lot of problems to developers. So we won't see anymore people in the 21st century asking how they can use printf(). I mean come on, the whole world is moving on and still we have to worry whether we want to link to this library or that. This sort of stuff has to have already been taken care of for the programmer before he starts coding with Assembly.
Posted on 2009-05-11 10:33:51 by XCHG
Why bother with this, since you're basically going to design a variant of C without the benefits of register allocation etc? You've already moved away from the one line = one instruction WYCIWYG that can be a benefit in assembly.
Posted on 2009-05-11 10:40:47 by f0dder
The difference in this dialect would be that you are writing a high-level assembly by having direct access to the registers. And the framework on top could be a series of highly optimized assembly routines that you will just call. So you ARE using assembly but in a modern way.
Posted on 2009-05-11 10:57:35 by XCHG
What do you think of C-- XCHG ?
http://www.goosee.com/cmm/

I would also add that I have been reading every assembly output of every C program I write and I'm usually satisfied by the quality of it.

- good register allocation
- pro use of local variables on the stack
- no need for stack frames
- can inline the code in the same module pretty well
- if you have link time code generation, it can inline functions from other modules
- good choice of instructions in general
- good switch
- bitfields/unions/structures are very decent

If you get used to read the generated code, it's almost like writing the assembly code yourself since you can predict what kind of code is made in advance.
Even after said all that, I don't believe that a compiler can outperform a human that knows what he's doing. Heck, if the compiler's better than me, i'll steal his code :D
95 % of the programmers you see will tell you that a compiler writes better code than a human. I'm annoyed by that comment everytime because that's simply not true. People who say that have never touched assembly but that phrase alone is enough to keep them from trying it.


Posted on 2009-05-11 11:24:10 by ChaperonNoir

What do you think of C-- XCHG ?
http://www.goosee.com/cmm/

I would also add that I have been reading every assembly output of every C program I write and I'm usually satisfied by the quality of it.

- good register allocation
- pro use of local variables on the stack
- no need for stack frames
- can inline the code in the same module pretty well
- if you have link time code generation, it can inline functions from other modules
- good choice of instructions in general
- good switch
- bitfields/unions/structures are very decent

If you get used to read the generated code, it's almost like writing the assembly code yourself since you can predict what kind of code is made in advance.
Even after said all that, I don't believe that a compiler can outperform a human that knows what he's doing. Heck, if the compiler's better than me, i'll steal his code :D
95 % of the programmers you see will tell you that a compiler writes better code than a human. I'm annoyed by that comment everytime because that's simply not true. People who say that have never touched assembly but that phrase alone is enough to keep them from trying it.


Oh no my point isn't this. My point is to make Assembly mainstream. Something that you would pick up if you want to write a commercial application quickly. So things that generally tidy up the syntax without going too far and without changing the language too much to make you feel like you are coding in another language.
Posted on 2009-05-11 11:31:07 by XCHG
HLA, C-- . Otherwise, MASM is pretty damn awesome, just look at this MASM code:




main proc
local fileName

local someFunc:IFUNC(hWnd,txt,capt,utype)
local file1,fileSize
local count1,tmp1
local allStrings


print "starting up"
msgbox "blah"

mov fileName,FetchFileData("configFile.txt")
prints fileName ; VKDebug PrintStringByAddr

mov file1,fopen(fileName,"rb")
mov fileSize,fsize(file1)

trace "Size of file %s is %d",fileName,fileSize

mov allStrings,new(ObjVector)
set allStrings as ObjVector

fread file1,addr count1,4

xor ecx,ecx
.while ecx<count1
fread file1,addr tmp1,4
mov eax,malloc(tmp1)
fread file1,eax,tmp1

pcall allStrings.add,eax

inc ecx
.endw

fclose file1


foreach allStrings, prints EDX


mov someFunc,MessageBox

invoke someFunc,0,T("blah2"),0,0


invoke strlen,fileName
DumpDataToFile "log.txt",fileName,eax

ret
main endp


...
class VarVector,,C++ compatible
void insert:ObjPtr,ObjSize
void delete:ObjPtr,ObjSize

void lock:
void unlock:

char isdead
char locked
char lock_insert
char lock_delete


long MyData
long BytesTaken
long PagesTaken

long _data2
long _data2_len
long _data3
long _data3_len

void _FlushInserts:
void _FlushDeletes:
endclass


It's only FPU stuff and multidimensional arrays, where asm can be a pain.
Posted on 2009-05-11 13:42:34 by Ultrano
You wish to make ASM mainstream again, but in order to do so, you need to change it so that it is everything but ASM?

Sounds like a bad case of nostalgia :lol:
Posted on 2009-05-11 14:04:03 by SpooK
95 % of the programmers you see will tell you that a compiler writes better code than a human. I'm annoyed by that comment everytime because that's simply not true. People who say that have never touched assembly but that phrase alone is enough to keep them from trying it.


Well, I wouldn't be surprised if 95% of all programmers won't be able to write better code than a compiler, so in a way it's almost true :)
Writing code that works in assembly is one thing, but being able to optimize it to make the CPU perform as fast as possible, that's something completely different altogether.
Posted on 2009-05-12 03:14:55 by Scali

HLA, C-- . Otherwise, MASM is pretty damn awesome, just look at this MASM code:




main proc
local fileName

local someFunc:IFUNC(hWnd,txt,capt,utype)
local file1,fileSize
local count1,tmp1
local allStrings


print "starting up"
msgbox "blah"

mov fileName,FetchFileData("configFile.txt")
prints fileName ; VKDebug PrintStringByAddr

mov file1,fopen(fileName,"rb")
mov fileSize,fsize(file1)

trace "Size of file %s is %d",fileName,fileSize

mov allStrings,new(ObjVector)
set allStrings as ObjVector

fread file1,addr count1,4

xor ecx,ecx
.while ecx<count1
fread file1,addr tmp1,4
mov eax,malloc(tmp1)
fread file1,eax,tmp1

pcall allStrings.add,eax

inc ecx
.endw

fclose file1


foreach allStrings, prints EDX


mov someFunc,MessageBox

invoke someFunc,0,T("blah2"),0,0


invoke strlen,fileName
DumpDataToFile "log.txt",fileName,eax

ret
main endp


...
class VarVector,,C++ compatible
void insert:ObjPtr,ObjSize
void delete:ObjPtr,ObjSize

void lock:
void unlock:

char isdead
char locked
char lock_insert
char lock_delete


long MyData
long BytesTaken
long PagesTaken

long _data2
long _data2_len
long _data3
long _data3_len

void _FlushInserts:
void _FlushDeletes:
endclass


It's only FPU stuff and multidimensional arrays, where asm can be a pain.


That's a good example of what I was thinking except that is still too long to type. Things like typing void this and void that in separate lines could be made easier by doinig void this, that; Things like this could make programming so much easier although they are just macros.
Posted on 2009-05-12 06:01:07 by XCHG
I think all of us know about the fact that that Assembly jobs are hard to find, people who create programs from scratch in Assembly for the end-user; are hard to find. And by programs I don't mean calculators and hobby programs. Something like Open Office for example. Things like that are bothering me about Assembly. I personally will never pick Assembly as a commercial language over other languages. I know some might argue that Assembly is not supposed to be used in that way but that's my main point of argument. A way to make it more mainstream and programmer-friendly as the title says so change it in a way that if you are asked to create a program really fast for a client, you pick Assembly over C#.NET or Delphi/C++ Builder for example. Perhaps a Framework? That's the best thing that comes to my head.
Posted on 2009-05-13 05:32:53 by XCHG
Well, since C++ and Delphi both allow you to use inline assembly, doesn't that already give you what you want?
You can use an IDE to quickly design any windows, dialogs and things... and when you need assembly, you can just put it inline where you want. You use the highlevel language when you want quick and easy development.
Posted on 2009-05-13 06:14:00 by Scali

Well, since C++ and Delphi both allow you to use inline assembly, doesn't that already give you what you want?
You can use an IDE to quickly design any windows, dialogs and things... and when you need assembly, you can just put it inline where you want. You use the highlevel language when you want quick and easy development.

Not really. I will code in Delphi if I pick Delphi and if there is some part of code is running REALLY slow, I might use some inline Assembly to optimize it. Because to me writing Assembly code takes longer than writing Delphi.

Now imaging if you could do this:

ECX = EBX + EDX * ECX + 3 / strlen(EAX);


This might seem not that useful. Well yeah it is not useful but my point is that small things in programming sometimes can have a big impact on the productivity of the programmer and his effectiveness, don't you think?

So if we had for example a framework to build on, I think it would be so much better. Am I the only person who thinks like this? Come onnnnnnnnn.
Posted on 2009-05-13 06:31:43 by XCHG
So generally, I think a combination of Framework + adding tons of macros and putting them into the framework + a kickarse IDE would make Assembly really useful in the real-world for commercial applications.
Posted on 2009-05-13 06:33:52 by XCHG
Sounds like OA32/RA :)
Posted on 2009-05-13 07:32:02 by Homer
Yeah Homer although RadASM is RAD compared to not having an IDE at all but it is RSD (Really Slow Development) compared to a commercial IDE in my opinion. I mean it's great but not good enough. God bless OA32 though.
Posted on 2009-05-13 07:37:24 by XCHG

Now imaging if you could do this:

ECX = EBX + EDX * ECX + 3 / strlen(EAX);



Yea well, add some symbolic names for the registers, and that's EXACTLY what Delphi or C++ will do for you.
Besides, why would you want that, instead of just:
c = b + d * c + 3 / strlen(a);

Why would you want to have the actual register names? Whatever registers the compiler picks will be fine.
Posted on 2009-05-13 08:16:13 by Scali
Maybe that wasn't a good example but the reason is that you can never be sure that the compiler is going to pick a register to do these calculations or not even if you ask it to. It has the right to ignore your inputs about that, isn't that right? I don't want to get too abstract with the details to be honest I just need to know why you guys think (if at all) that Assembly is really not chose for majority of commercial applications out in stores today?

If assembly is going to be used just for heavily optimized parts of high level language programs, then with the speed of improvements of hardware, soon Assembly is going to be phased out completely and be a memory in a couple of years. Hardware is becoming cheaper and cheaper every day. I don't think it's going to be so important for a 3D engine in about 20 years for example if it calculates the distance between a point and a line in 2 clock cycles less than the equivalent C code for example.

So basically my point of view is not from the performance side of things.
Posted on 2009-05-13 08:27:10 by XCHG
Why would you want to have the actual register names? Whatever registers the compiler picks will be fine.
Yeah, at least for trivial code like this - and when you need überspeed and hand allocation, just how often do you need to call external routines? Also, you tend to need to interleave instructions, which means you can't use the highlevel assembly construct anyway.

The idea seems entirely pointless to me. You'd only find a handful of niche developer who think this could be a good idea... most will prefer either having a strong static typed language that can detect a lot of problems at compile-time (and offers power static analysis), or a dynamic language where type information can be determined at runtime. Assembly falls flat between those two chairs (some assemblers does at least support types, but then you're stuck with retard header files that assumes everything is a DWORD).

If you think static typing is a bad thing, you've probably spent too much time writing boring code that does little but interface with the PlatformSDK... which is a prime example of a package that is hellish to use because of it's legacy, and could do with a nice rewrite - you do need an insane amount of typecasting all over the place when using the PSDK in anything higher but C.
Posted on 2009-05-13 08:31:12 by f0dder
Now imaging if you could do this:

ECX = EBX + EDX * ECX + 3 / strlen(EAX);


This might seem not that useful. Well yeah it is not useful but my point is that small things in programming sometimes can have a big impact on the productivity of the programmer and his effectiveness, don't you think?


strlen has side-effects (meaning it may change the volatile registers eax, ecx, edx) which this language does not make the programmer aware of. This will make the code very hard to read, because you, as a programmer, have to be aware of all these side-effects. That is why compilers, like Scali said, are better off to work with variables, not registers directly. The compiler should figure out best which registers to spill the variables onto and when - if you don't like that, then use inline asm.
Posted on 2009-05-13 08:51:11 by comrade

Now imaging if you could do this:

ECX = EBX + EDX * ECX + 3 / strlen(EAX);


This might seem not that useful. Well yeah it is not useful but my point is that small things in programming sometimes can have a big impact on the productivity of the programmer and his effectiveness, don't you think?


strlen has side-effects (meaning it may change the volatile registers eax, ecx, edx) which this language does not make the programmer aware of. This will make the code very hard to read, because you, as a programmer, have to be aware of all these side-effects. That is why compilers, like Scali said, are better off to work with variables, not registers directly. The compiler should figure out best which registers to spill the variables onto and when - if you don't like that, then use inline asm.


Are you referring to a simple PUSH and POP? I mean that could be taken care of if the coder(s) of the framework know what they are doing.
Posted on 2009-05-13 08:59:41 by XCHG