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.


Well I have recently been coding with Objective C and Apple iPhone and we have released (with a great help from Ilian) an application for Walkers which is called Walkers Flavour Racers on the Apple Store. The next one is for O2 so to be honest, I think I know what I'm talking about when I say these, commercially speaking, these things are not even counted when it comes to selling applications. I think it depends what your reasons are for coding. If you want to actually sell applications, Assembly will definitely will be the last programming language in the list of choices since it takes a lot of time to develop a simple application, not many people know it (because of its complexity, the amount of time it needs to develop applications and etc) and many others.
Posted on 2009-05-13 09:02:51 by XCHG
XCHG: ...which are all great reasons it doesn't make sense trying to make something to cater for a lot of developers, or to try and make assembly a "viable commercial production language". We use it for speed or because we plain enjoy it, and imho that's a fine enough position for the language - aside for those two reasons (which can be justification enough!), imho other languages are better for most purposes.

The thing *I* enjoy about assembly is WYCIWYG and full control of the CPU - if I want high-level code, I use a high(er)-level language. YMMV :)
Posted on 2009-05-13 09:08:29 by f0dder

XCHG: ...which are all great reasons it doesn't make sense trying to make something to cater for a lot of developers, or to try and make assembly a "viable commercial production language". We use it for speed or because we plain enjoy it, and imho that's a fine enough position for the language - aside for those two reasons (which can be justification enough!), imho other languages are better for most purposes.

The thing *I* enjoy about assembly is WYCIWYG and full control of the CPU - if I want high-level code, I use a high(er)-level language. YMMV :)


You think I don't enjoy Assembly? I really do but it bothers me that I can't pick it as a language to do a commercial application with knowing the potential of Assembly.
Posted on 2009-05-13 09:33:03 by XCHG
No no, I do think you enjoy assembly :) - I just stated why I enjoy it, which might not be the same for everybody else - as I wrote, YMMV.
Posted on 2009-05-13 09:35:49 by f0dder

No no, I do think you enjoy assembly :) - I just stated why I enjoy it, which might not be the same for everybody else - as I wrote, YMMV.


Yeah I also love the fact that Assembly, once you understand the whole structure, instruction set and etc, is the easiest and the most powerful way of writing programs. These are the things that I wanted to solve:

1) Nobody will ever pick Assembly as a language to write commercial applications.
2) Assembly will eventually be phased out considering how fast HW is becoming more and more advanced.
3) Using Assembly will eventually become useless considering the great deal of time put into making compilers more and more sophisticated.
Posted on 2009-05-14 04:25:47 by XCHG
I know what you want man.
You want a new half-way language, something that is quick to develop without losing control.
Join us!
Posted on 2009-05-14 06:11:01 by Homer
What about PB? For example code snippet:
http://www.powerbasic.com/support/pbforums/showpost.php?p=315270&postcount=7

There is always the possibility of writing your own compiler/assembler. That's a lot of work though (but quite rewarding.)
Posted on 2009-05-14 13:06:19 by MarkJ
This paradox is obviously solved with VS2k5+ C++ : you have inline asm in x86, the HLL parts are compiled+optimized very nicely, your own external .asm code is inspected by the linker and nicely inlined (with almost-perfect register allocation around your inspected asm code). The inline asm is barebones but has easy access to the local HLL symbols, while the external .asm files can use powerful macros. Then, intrinsics to automatically allocate registers (be it in static or inlined context). Add to that knowledge of the compiler's output, and together all those features create the holy grail: complete power+flexibility+ease+optimization+anything at your tips at any time, without the huge drawbacks we're used to get when choosing a path in the current line of code.
Posted on 2009-05-14 13:59:10 by Ultrano
Ultrano, are you sure that we can inline external ASM code? Do you have an example handy?
Posted on 2009-05-14 15:41:21 by ChaperonNoir
Well, actually external asm is not inlined (I just observed good register-allocation around calls to it), but inline asm is.
Posted on 2009-05-14 16:00:30 by Ultrano
C++ isn't perfect, though - especially not when you do win32 API level programming, since the PlatformSDK was clearly designed back in the C days, and not really brought up to date. Too many typecasts needed, ugly use of the preprocessor (ever tried having a WriteFile member function in one of your classes?), and the C++ standard library isn't as rich as some of the newer languages... not to mention that libc string functions are evil, and C++'s std::string sucks. I still like the language, though, and it is very powerful and flexible, and has compilers that generate nice code.

Are you sure the compiler/linker analyzes external modules wrt. register allocation, though? I've never heard of such a feature, and it would seem like quite some work. Isn't it just that it knows about standard calling conventions and tries to optimize for that?

Also, inline assembly doesn't work for x64 compilers. I don't really see this as a problem, though, since anything worth writing in assembly is usually worth writing in an external module.

Oh, and I'm not a super huge fan of MMX/SSE/whatever intrinsics - the idea is great, but when I (who, admittedly, isn't the supermosthardcore optimizer :)) can get quite better results than the compiler spits out, it has a way to go yet. But intrinsics aren't portable anyway, so you might as well go and write assembly... unless you're using intrinsics for prototyping and then go and hand-optimize afterwards.

As for PowerBASIC... I'd stay clear of it. It has awful code generation, the language is pretty unflexible and limited, the only way of using external modules is through DLLs, and you kinda have to drop to inline assembly to get decent performance when you aren't doing simple API-bound stuff. And the debugger sucks.
Posted on 2009-05-14 17:45:42 by f0dder
Hehe, I completely agree with you f0dder.

And all these obvious typecasts always get on my nerves. They all do nothing, but you always need them. It seems that if you compile your code as C code you don't need them but who would want to do that?

Not to mention the DLL hell. If you Release with Visual 2005, you need to install the winsx redistributable package for 2005. If you release with Visual 2008 (like me), you need to install the redistributable package for 2008. There's like no way to easily link to the good old standard MSVCRT.DLL with Visual Studio 2005/2008. It seems that the GNU tools on Windows link to MSVCRT.DLL, maybe I try to convert some of my projects to the GNU compiler.


Posted on 2009-05-14 21:20:10 by ChaperonNoir
ChaperonNoir: yes, the libc DLL situation with newer Visual C is hell, and it's damn annoying, and I'm not particular fond of having to use .msi installers to get "clean" installs... using the redistrutable exe installer sucks, and dropping the runtime DLLs to each of your installed application folders does too. Sigh. But I wouldn't want to use old MSVCRT.DLL either.

The PlatformSDK could be - at least mostly - fixed up to behave nice with C++, but it would be a gigantic undertaking. At least outside the domain of small programs, you aren't/shouldn'tbe spending most of your time with API code and typecasts :)
Posted on 2009-05-15 03:27:39 by f0dder
ChaperonNoir, you should try intel compiler, it's way waay more relaxed with the need for typecasting than ms compiler. Oh, and cl with /Zl switch and msvcrt.lib passed to linker should work...
Posted on 2009-05-15 09:02:48 by drizz
ChaperonNoir, you should try intel compiler, it's way waay more relaxed with the need for typecasting than ms compiler.
It can't be, since it wouldn't be following the standard. Are you compiling in C rather than C++ mode?

Oh, and cl with /Zl switch and msvcrt.lib passed to linker should work...
Probably unsafe - there's things here and there in libc/c++ that depend on the data structure (as defined in the headers) - using the 2005/2008 headers but linking against generic old MSVCRT isn't something I'd recommend (having just experienced a game that was linked against old msvcrt headers, and crashed when running against a more recent library).
Posted on 2009-05-15 10:41:31 by f0dder
yes f0dder c++ mode.

small example:
coffeedev.cpp(15) : error C2664: 'CoffLib::Open' : cannot convert parameter 1 from 'const char [9]' to 'unsigned char *'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
coffeedev.cpp(40) : error C2664: 'CoffObj::Open' : cannot convert parameter 1 from 'PDWORD' to 'BYTE *'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
coffeedev.cpp(49) : error C2664: 'strncmp' : cannot convert parameter 1 from 'BYTE (*)[8]' to 'const char *'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
coffeedev.cpp(56) : error C2664: 'strncmp' : cannot convert parameter 1 from 'BYTE (*)[8]' to 'const char *'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
coffeedev.cpp(71) : error C2440: '=' : cannot convert from 'PBYTE' to 'PIMAGE_SYMBOL'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
coffeedev.cpp(122) : error C2664: 'CoffImage::Open' : cannot convert parameter 1 from 'const char [9]' to 'BYTE *'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
coffeedev.cpp(134) : error C2440: 'initializing' : cannot convert from 'BYTE *' to 'PIMAGE_IMPORT_DESCRIPTOR'
        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

Those are the only errors that cl shows but not icl. Anyway, i think we are offtopic  :)
Posted on 2009-05-15 14:54:33 by drizz

ChaperonNoir, you should try intel compiler, it's way waay more relaxed with the need for typecasting than ms compiler. Oh, and cl with /Zl switch and msvcrt.lib passed to linker should work...


I have it and I think it's a good compiler if you remove the totality of the Runtime and keep only the code.
The following C code gives this assembly code, I think that the compiler is doing a good job here.
Extern "C" is something I like to add but here it's not necessary because the entry point is passed to the linker via commandline.

#include <stdio.h>
#include <string.h>

extern "C" void mainCRTStartup()
{
static char myString[] = "hello";
printf(myString);

int size = strlen(myString);
printf("%d",size);

}

       ALIGN     16
PUBLIC _mainCRTStartup
_mainCRTStartup PROC NEAR
.B1.1:                          ; Preds .B1.0

;;; {

$LN1:
$LN3:

;;; static char myString[] = "hello";
;;; printf(myString);

        push      OFFSET FLAT: myString.9660.0.1                ;7.9
$LN5:
        call      DWORD PTR [__imp__printf]                     ;7.2
                                ; LOE ebx ebp esi edi
.B1.6:                          ; Preds .B1.1
        pop       ecx                                           ;7.2
                                ; LOE ebx ebp esi edi
.B1.2:                          ; Preds .B1.6
$LN7:

;;;
;;; int size = strlen(myString);

        mov       ecx, OFFSET FLAT: myString.9660.0.1           ;9.13
        xor       eax, eax                                      ;9.13
L4:                                                             ;
        movzx     edx, BYTE PTR                        ;9.13
        test      edx, edx                                      ;9.13
        je        L3            ; Prob 50%                      ;9.13
        movzx     edx, BYTE PTR [1+ecx+eax]                     ;9.13
        add       eax, 2                                        ;9.13
        test      edx, edx                                      ;9.13
        jne       L4            ; Prob 50%                      ;9.13
        dec       eax                                           ;9.13
L3:                                                             ;
                                ; LOE eax ebx ebp esi edi
.B1.7:                          ; Preds .B1.2
        push      eax                                           ;9.13
        push      OFFSET FLAT: ??_C@_02A@?$CFd?$AA@             ;9.13
$LN9:

;;; printf("%d",size);

        call      DWORD PTR [__imp__printf]                     ;10.2
                                ; LOE ebx ebp esi edi
.B1.8:                          ; Preds .B1.7
        add       esp, 8                                        ;10.2
                                ; LOE ebx ebp esi edi
.B1.3:                          ; Preds .B1.8

;;;
;;; }
$LN11:
        ret                                                     ;12.1
        ALIGN     16
                                ; LOE
; mark_end;
_mainCRTStartup ENDP


You have to admit that this is good code. And I'd say that the Visual C++ code is even better. This code is linked with MSVCRT.DLL using msvcrt.lib from MASM32\lib\ and it will work on every version of windows thanks to that.
Posted on 2009-05-15 17:51:57 by ChaperonNoir