Language closest to assembly

[luke77]

I program using masm.exe and assembly.

I can't find any assembly forums or groups in MSFN.

What language comes closest to assembly and I will look for groups for it.

Thanks.

[CoffeeFiend]

I program using masm.exe and assembly

A lot of us were into it back then (I mean, in the DOS days; I was more of a TASM guy though). There might be some people who are still into it. I did have some fun with ml64, but there's just no way I'm still going to develop PC apps in assembly in this day and age.

I can't find any assembly forums or groups in MSFN

There isn't one. The closest thing is this place, which is mostly used for batch files and simple scripting anyway (not a whole lot of "real" programming)

[tain]

Maybe just try C for a while? It is probably the lowest-level of the major languages currently in use. And you can always fall back to in-line asm if you get uncomfortable.

[Fredledingue]

What are you talking about?

Programmers today are using an extended form of Assembly which uses windows API's. I forgot the exact name of this language but it's still Assembly and you can use pure old assembly code into it if you want.

Assembly is still the language of top programmers.

[tain]

asm that invokes OS APIs? asm inherently invokes cpu opcodes so I'm not quite sure how that would work. Sounds neat, though.

[cluberti]

Sounds like some sort of C or C++ wrapper to ASM, which can be done anyway in any C or C++ project in VS at least. However, if it's *true* ASM and it has a way to make Win32 calls, that'd be mighty interesting.

[tain]

You mean like the in-line asm I mentioned? Thought there is no API interface there that I know about.

[CoffeeFiend]

What are you talking about?

...right back at you?

Programmers today are using an extended form of Assembly

Extended form? I'd like to see references to that stuff. I never heard of anything like this, much less that is commonly used today.

which uses windows API's

Hmmm, what am I missing here? You can make API calls from plain old asm no problem. You declare the call as extern and compile using the right .lib's -- sample code on request.

Assembly is still the language of top programmers.

And you say this based on what evidence? Most "top programmers" I've seen or heard of don't write in assembly. Not because they're unable to (seriously, writing basic asm isn't hard at all and there's plenty of n00bs who are into it too) but rather because it's a waste of resources (time and money) in the vast majority of cases. And even in the "top rated" places that supposedly grab all the new super great programmers, they're still into other languages. Like Google (C++/Java/Python/JavaScript mainly), or Microsoft (mainly C/C++ AFAIK), or Apple (C/C++/Objective C), several others like IBM and Oracle (C/C++/Java), etc.

There's plenty of great programmers (who know several complex languages better than I ever will, that seemingly knows every algo and pattern and when to apply them, etc) but just aren't quite as good as most good modern compilers at writing fast asm code. It's not like the the early DOS days where it was trivial to completely PWN turbo pascals' speed (although some BASM or OBJ's compiled in TASM still did the trick to speed up the slow parts without quite having to write every single thing in asm). These days are long gone. Unless you you can write SSE2+ level assembly (including all the fancy SIMD instructions), can do instruction ordering, can keep the pipelines full on fancy multi-core CPUs (and keeping in mind things like how NUMA architectures work and other fancy things), preventing cache misses, etc. Most people just aren't able to match a good C/C++ compiler these days (myself included).

It takes FAR more time to write anything this way (massive waste of time) with often VERY little gain (it's really premature optimization), it's not portable between different CPU lines (yes, there is life besides x86 -- ARM, MIPS, PPC and plenty of microcontroller series), or even different "bitness" of the same CPU line (e.g. 16 bit code on a x64 OS, or x64 code on a x86 OS), between different OS'es, etc. So you have to keep several versions of your code which differ quite a bit from each other, and manually optimizing your code for each major CPU "revision" too (different instruction sets available, different architectures, etc) which is extremely time consuming and rather hard. Nevermind the extra complexity it adds (requiring higher qualified programmers to do a great job, which cost significantly more and are a lot harder to find), the very high overhead of maintaining and debugging it (various versions which each have many times more LOCs), etc. So it's no wonder hardly any companies want to make use of it (besides those making specialized things, like compilers or 3D engines for games) as it's totally not cost effective in the vast majority of situations (it mainly seems like a way to ship late & over-budget, and making it even harder finding qualified personnel). That makes it a skill that's not all that marketable, unless you intend to apply on a rather specialized job. Even in the embedded world we're writing a whole lot more C than asm these days. And on the "desktop apps" side, most (90% perhaps) of what I see is still plain old C++/MFC with some .NET and other stuff.

Edit: Bored. Here's a really simple hello world type app, written in x64 asm. It pops up a messagebox, and sets the exit code to whichever button's value was pressed. Compile with ml64 (found in "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64" for those using VS2010). Assuming your lib search path ("LIB" env var) is set properly (i.e. includes "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64" or similar), you can compile it with (you could use includelib in the file too):

ml64 something.asm /link /subsystem:windows /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:main

extrn MessageBoxA: PROC
extrn ExitProcess: PROC

.data
capt db 'Hallo Welt', 0
msg db 'MSFN',13,10,'ROX!',0

.code
main proc
  sub rsp, 28h     ;adjust/align stack
  ;1st arg in rcx, 2nd in rdx, 3rd in r8, 4th in r9; FP in XMM0..XMM3; remaining on stack; return val in rax
  mov r9d, 43h     ;uType MB_YESNOCANCEL | MB_ICONINFORMATION; 32 bit value so r9d
  lea r8,  capt    ;LPCSTR lpCaption
  lea rdx, msg     ;LPCSTR lpText
  mov rcx, 0       ;hWnd HWND_DESKTOP (xor rcx,rcx would work too)
  call MessageBoxA
  mov ecx, eax     ;set 1st param to MessageBoxA's returned value
  ;add rsp, 28h    ;clean up the stack (purely optional before calling ExitProcess)
  call ExitProcess
main endp

End

While this is trivial, writing a complete desktop app this way (all the controls, all the message handling, all the code to do what it's meant for, etc) would be totally insane. It would literally take me over a year full time to accomplish what I can do in a couple hours using c# and winforms (but yeah, it would use 5MB less of RAM... and probably be full of bugs, not feature complete, late, over budget, not available in native x64, etc)

[jaclaz]

OT , but not much .

Try this WinExplorer:

http://www.quickersoft.com/donkey/

http://www.quickersoft.com/donkey/winexplorer.htm

jaclaz

[luke77]

asm that invokes OS APIs? asm inherently invokes cpu opcodes so I'm not quite sure how that would work. Sounds neat, though.

Check out these sites and see Win32 assembly in action.

http://www.asmcommunity.net/board/index.php

http://www.masm32.com/board/index.php?