Author Topic: High Level Language in MASM  (Read 59297 times)

nidud

  • Member
  • *****
  • Posts: 1386
    • https://github.com/nidud/asmc
Re: High Level Language in MASM
« Reply #15 on: November 14, 2012, 04:04:18 AM »
Thanks for the encouragement habran, but I have to admit that I am a bit old-fashioned myself. I think it is a bad idea that more/newer is always better, and then (for this reason) assume the future will be good.

As for me, however, I'm one of those guys who don't believe in progress.
I have spent a lot of my time travelling, viewing the result of this alleged progress, so I must (sadly as it is) agree with you there.

The reason for this idea comes from experience with assembly in general, and could be summed up like this: I have used assembler language for a long time, but normally only as a supplement to applications written in C/C++. At one point I converted a whole application to assembly, and the difference it made was quite astonishing. The size was cut in half and the speed of the program dramatically increased. Needless to say I was happy with the result, but at this time I had to leave. After a few weeks on returning I had some ideas on improving the program, and also some new features that I wanted to add. I then discover the problem with assembly: it only took a few weeks to forget how the thing works. If someone will ask me today if this is a good idea, I will use this experiment to explain the benefits, but then also add the following: you better get it right the first time because you wont be able to apply changes to it later.

The main problem in this context is readability, and I think that is the reason why so few applications are written in assembly. So the main idea here is to make it possible to write readable code, and thereby maintainable code. These problems only occur on large projects, and the suggested changes will therefore only applies to people who have this in mind.

This is also why the interpreters was made: to converts macro language (in this case C) to assembly code. The interpreter used by MS is called CL, and (JJ) this is how it works:
Code: [Select]
/* repeat.c */
int repeat(void)
{
    int eax = -3;
    int ecx = 5;

    do { eax++; } while (--ecx);
    return eax;
}
cl -c –Farepeat.asm repeat.c
Code: [Select]
TITLE repeat.c
.386P
include listing.inc
if @Version gt 510
.model FLAT
else
_TEXT SEGMENT PARA USE32 PUBLIC 'CODE'
_TEXT ENDS
_DATA SEGMENT DWORD USE32 PUBLIC 'DATA'
_DATA ENDS
CONST SEGMENT DWORD USE32 PUBLIC 'CONST'
CONST ENDS
_BSS SEGMENT DWORD USE32 PUBLIC 'BSS'
_BSS ENDS
_TLS SEGMENT DWORD USE32 PUBLIC 'TLS'
_TLS ENDS
FLAT GROUP _DATA, CONST, _BSS
ASSUME CS: FLAT, DS: FLAT, SS: FLAT
endif
PUBLIC _repeat
_TEXT SEGMENT
_eax$ = -4
_ecx$ = -8
_repeat PROC NEAR
; File repeat.c
; Line 3
push ebp
mov ebp, esp
sub esp, 8
; Line 4
mov DWORD PTR _eax$[ebp], -3 ; fffffffdH
; Line 5
mov DWORD PTR _ecx$[ebp], 5
$L34:
; Line 7
mov eax, DWORD PTR _eax$[ebp]
add eax, 1
mov DWORD PTR _eax$[ebp], eax
mov ecx, DWORD PTR _ecx$[ebp]
sub ecx, 1
mov DWORD PTR _ecx$[ebp], ecx
cmp DWORD PTR _ecx$[ebp], 0
jne SHORT $L34
; Line 8
mov eax, DWORD PTR _eax$[ebp]
; Line 9
mov esp, ebp
pop ebp
ret 0
_repeat ENDP
_TEXT ENDS
END

This illustrates how good (as in readable) the C language is, and how good the assembly language become if you code the loop yourself.

The HLL section made by MS emulates the C language, so readability means that all extensions made must be common. Comment should describe what the function does, not how it actually do it. The body of the function must then be written in a way that it explains itself. This means that you can’t introduce a lot of new things in order to achieve this, so you need to use the old (conservative if you will) methods included. Some other conservative people allegedly steal these functions. If you focus more on the actual intention of the HLL section, and what hutch is saying, the purpose of it is usage, not antiquity.

The question to answer will then be why you don’t use the HLL directives, and what needs to change in order for you to consider using it. My argument will be to enable me to read my own dribble, if I want to make changes to it later. The optimal result will be to enable others to read (and understand it) as well, so they could apply changes to it.

Therefore I'm very reluctant to accept "extensions" for jwasm. Perhaps you should consider to start a fork, with it's own name ( nwasm? ).
This is just an idea at the moment, and the enthusiasm currently only serves selfish interest. This could not happen without the source code provided by you. If there is an interest in implementing these changes, there will be many extensions made, so in this case I will consider making a fork. CASM will not make changes that makes problems for existing code, so it will still be JWASM with some added features.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 4874
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: High Level Language in MASM
« Reply #16 on: November 14, 2012, 09:31:20 AM »
> The main problem in this context is readability

The assumption that C language format will improve readability of MASM code would be a hard idea to sell, MASM and by derivation JWASM already has a macro language that is far more powerful than the C preprocessor and it already has the notation for higher level loop structures, conditional branching and variation on single line function calls. It is part of the appeal of using a macro assembler that you can perform a task in a number of different ways from purely manual mnemonics to reasonably high level notation.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

nidud

  • Member
  • *****
  • Posts: 1386
    • https://github.com/nidud/asmc
Re: High Level Language in MASM
« Reply #17 on: November 14, 2012, 10:39:30 AM »
The assumption that C language format will improve readability of MASM code would be a hard idea to sell
You don’t have to; it’s already a fact (that C language improves readability that is).

MASM and by derivation JWASM already has a macro language that is far more powerful than the C preprocessor and it already has the notation for higher level loop structures, conditional branching and variation on single line function calls. It is part of the appeal of using a macro assembler that you can perform a task in a number of different ways from purely manual mnemonics to reasonably high level notation.
True, it will outperform C on all levels, except from one: portability.

jj2007

  • Member
  • *****
  • Posts: 7635
  • Assembler is fun ;-)
    • MasmBasic
Re: High Level Language in MASM
« Reply #18 on: November 14, 2012, 10:45:34 AM »
You don’t have to; it’s already a fact (that C language improves readability that is).

Over one Billion people are firmly convinced that Chinese is the World's most readable language 8)

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 4874
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: High Level Language in MASM
« Reply #19 on: November 14, 2012, 11:01:14 AM »
 :biggrin:

> You don’t have to; it’s already a fact (that C language improves readability that is).

The problem is the world is full of people who write other languages that don't agree. I grew up with K & R C notation and formatting so I read it OK but it is an archaic notation that irks many people including those who write Pascal, Basic, Fortran, VB dialects etc etc. Nested braces {}, trailing line terminators ";", the need for "break" etc, its ancient notation that was long ago left behind. Thank God for the clarity and precision of MASM.  :P
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

nidud

  • Member
  • *****
  • Posts: 1386
    • https://github.com/nidud/asmc
Re: High Level Language in MASM
« Reply #20 on: November 14, 2012, 11:08:21 AM »
Over one Billion people are firmly convinced that Chinese is the World's most readable language 8)
Think you will find that more than five billion will disagree on that one :lol:

nidud

  • Member
  • *****
  • Posts: 1386
    • https://github.com/nidud/asmc
Re: High Level Language in MASM
« Reply #21 on: November 14, 2012, 11:17:32 AM »
The problem is the world is full of people who write other languages that don't agree. I grew up with K & R C notation and formatting so I read it OK but it is an archaic notation that irks many people including those who write Pascal, Basic, Fortran, VB dialects etc etc. Nested braces {}, trailing line terminators ";", the need for "break" etc, its ancient notation that was long ago left behind. Thank God for the clarity and precision of MASM.  :P
No need to import all that crap :biggrin:
This will do for starters:
Code: [Select]
.if ((ecx = strlen(string)) > edi)

dedndave

  • Member
  • *****
  • Posts: 8741
  • Still using Abacus 2.0
    • DednDave
Re: High Level Language in MASM
« Reply #22 on: November 14, 2012, 11:57:48 AM »
i don't know why you MUST write in hll ???
afterall, if you want your code to look like C, write it in C - lol
if i want to use LOOPNZ, i can do it by using.....  LOOPNZ   :biggrin:

as for Hutch's comment about those instructions being slower...
we may need to re-test those instructions with newer cores
they may be slower on a P4, but not his new-fangled i7

japheth

  • Guest
Re: High Level Language in MASM
« Reply #23 on: November 14, 2012, 02:33:31 PM »
how dare you to say that!!!  :icon_eek:

The term "to believe in" isn't always used in the context of "to believe in the existence of"; this is a technical usage. A more philosophical usage of this term is "to believe in the concept or idea of" - and this latter view was meant here.

habran

  • Member
  • *****
  • Posts: 1114
    • uasm
Re: High Level Language in MASM
« Reply #24 on: November 14, 2012, 03:44:20 PM »
japheth,

I found this in TheFreeDictionary
progress:
1. Movement, as toward a goal; advance.
2. Development or growth: students who show progress.
3. Steady improvement, as of a society or civilization: a believer in human progress. See Synonyms at development.

what I want to say is: The Perfection is most probably inaccessible to us humans
however, that doesn't mean that we should give up on trying to become one  ;)

regards :biggrin:
Cod-Father

habran

  • Member
  • *****
  • Posts: 1114
    • uasm
Re: High Level Language in MASM
« Reply #25 on: November 14, 2012, 03:49:44 PM »
nidud

consider this:

"rbx=qwinvoke(strlen,ADDR src)"  is not neccecery in this function
 I'v just put it there to show how it works

Code: [Select]
qwinvoke MACRO Fun:REQ, A:VARARG
  IFB <A>
    invoke Fun
  ELSE
    invoke Fun, A
  ENDIF
  EXITM <rax>
ENDM


xmemcpy PROC FRAME USES rbx dest:QWORD,src :QWORD, count:UINT_PTR

  .if (rcx != rdx) 
  .for (rbx=qwinvoke(strlen,ADDR src)¦r8¦al=[rdx],[rcx]=al,rcx++,rdx++,r8--)
        .break .if (r8 > rbx)
  .endfor
  .endif
  mov rax,dest
  ret
xmemcpy ENDP

xmemcpy:
00000000004935B0  mov         qword ptr [rsp+8],rcx
00000000004935B5  mov         qword ptr [rsp+10h],rdx
00000000004935BA  mov         qword ptr [rsp+18h],r8
00000000004935BF  push        rbp 
00000000004935C0  mov         rbp,rsp
00000000004935C3  sub         rsp,20h
00000000004935C7  cmp         rcx,rdx
00000000004935CA  je          xmemcpy+46h (4935F6h)
00000000004935CC  lea         rcx,[rbp+18h]
00000000004935D0  call        strlen (4246E0h)
00000000004935D5  mov         rbx,rax
00000000004935D8  jmp         xmemcpy+3Ah (4935EAh)
00000000004935DA  mov         al,byte ptr [rdx]
00000000004935DC  mov         byte ptr [rcx],al
00000000004935DE  add         rcx,1
00000000004935E2  add         rdx,1
00000000004935E6  sub         r8,1
00000000004935EA  and         r8,r8
00000000004935ED  je          xmemcpy+46h (4935F6h)
00000000004935EF  cmp         r8,rbx
00000000004935F2  ja          xmemcpy+46h (4935F6h)
00000000004935F4  jmp         xmemcpy+2Ah (4935DAh)
00000000004935F6  mov         rax,qword ptr [rbp+10h]
00000000004935FA  add         rsp,20h
00000000004935FE  pop         rbp 
00000000004935FF  ret             


regards
Cod-Father

nidud

  • Member
  • *****
  • Posts: 1386
    • https://github.com/nidud/asmc
Re: High Level Language in MASM
« Reply #26 on: November 15, 2012, 01:35:38 AM »
i don't know why you MUST write in hll ???
I don’t; nobody does.
afterall, if you want your code to look like C, write it in C - lol
I do, because I MUST: JWasm is written in C.
...
all the programs in the \masm32\bin directory are written in C.
all the library source code in the \masm32\lib directory is written in C.

if i want to use LOOPNZ, i can do it by using.....  LOOPNZ   :biggrin:

as for Hutch's comment about those instructions being slower...
we may need to re-test those instructions with newer cores
they may be slower on a P4, but not his new-fangled i7
Ok.

habran

consider this:

Code: [Select]
.data
s1 db 'abcdefgh',0
s2 db 'abcd',0
.code
start:
.for (ebx = offset s1, edx = func(strlen,ebx) ¦ edx >= sizeof(s2) ¦ edx--)
    mov byte ptr [ebx+edx-1],0
.endfor
invoke printf,cstr(<"s1: %s",10,"s2: %s",10>),ebx,addr s2
output:
s1: abcdefgh
s2: abcd
...
mov ebx,offset s1
.for (edx = func(strlen,ebx) ¦ edx >= sizeof(s2) ¦ edx--)
output:
s1: abcd
s2: abcd

This is what a delayed expansion of macros does, and this is what is done with .elseif <expression> and .while <expression>.

In this case the code will expand to:
* invoke strlen,ebx
.for (ebx = offset s1, edx = eax…

For this to work, the .for <expression> must also delay the expansion of <expression>, and you have to do the actual expansion inside your code.

Code: [Select]
.for (ebx = offset s1, edx = func(strlen,ebx) ¦ edx >= func(strlen,addr s2) ¦ edx--)or, since you parse the .for[...] locally, the macro could be removed
Code: [Select]
.for (ebx = offset s1, edx = strlen(ebx) ¦ edx >= strlen(addr s2) ¦ edx--)

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 4874
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: High Level Language in MASM
« Reply #27 on: November 15, 2012, 02:00:03 AM »
 :biggrin:

Quote
all the programs in the \masm32\bin directory are written in C.
all the library source code in the \masm32\lib directory is written in C.

Tell us something new, Microsoft binaries are written in C or C++ but the stubs that are too small for C in the bin directory are written in MASM, LIB.EXE, DUMPBIN.EXE and EDITBIN.EXE. The complete LIB directory import libraries were created at install with ML.EXE.

We have all heard C zealots before waxing lyrical about its supposed superiority but long ago assembler produced binaries that are beyond the best C compilers, this is mainly why assembler programmers still exist. No high level language owns assembler, C interfaces with it fine, many dialects of basic write sound assembler and from memory even Pascal can produce assembler output but assembler is a language in its own right that has little need for the constraints of C or C++. It does EXE, DLL and OBJ file just fine without a C compiler.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

CommonTater

  • Guest
Re: High Level Language in MASM
« Reply #28 on: November 15, 2012, 02:15:21 AM »
We have all heard C zealots before waxing lyrical about its supposed superiority but long ago assembler produced binaries that are beyond the best C compilers, this is mainly why assembler programmers still exist. No high level language owns assembler, C interfaces with it fine, many dialects of basic write sound assembler and from memory even Pascal can produce assembler output but assembler is a language in its own right that has little need for the constraints of C or C++. It does EXE, DLL and OBJ file just fine without a C compiler.

At the risk of stepping in it...

I prefer C because I know C.  When I was working mostly in Pascal, I preferred Pascal because I knew Pascal.  I think it's just human nature to want to think we've hooked ourselves up with "all the right stuff" whether we have or not. 

I don't see ASM, C, C++, C# and a hundred other languages I will never use as competing with one another.  I see them as complimentary... each having a place according to their own strengths.

dedndave

  • Member
  • *****
  • Posts: 8741
  • Still using Abacus 2.0
    • DednDave
Re: High Level Language in MASM
« Reply #29 on: November 15, 2012, 02:22:51 AM »
yes - they do have their place
i tried other languages in days of old
but always came back to assembler because of some limitation from the compiler   :P

if i were writing apps on a professional basis, i would probably use C with some asm-created OBJ's