Recent Posts

Pages: [1] 2 3 ... 10
1
The Campus / Re: Beginner question - would this work on any CPU?
« Last post by jj2007 on Today at 10:47:38 PM »
I want to learn assembly, to make programs for Windows only. I believe I should learn MASM32?

Yes. Practically all Windows computers understand x86. Programs written in Masm32 ten years ago run just fine on the latest Windows 10 version.

Welcome to the Forum :icon14:
2
The Campus / Beginner question - would this work on any CPU?
« Last post by securityaudit on Today at 09:44:30 PM »
Hello MASM32,

I have spent a few years coding in C and Java. I enjoy how I can make a program display a message box or perform some file operations and it works on every (I think?) CPU without any dramas. Although I have never coded anything advanced.

I want to learn assembly, to make programs for Windows only. I believe I should learn MASM32?

My question: provided I do not want to do something too crazy or obscure, will programs I create work on every CPU? My focus is on your average computer at home or perhaps servers. Not anything super obscure that mad scientists have in their labs (sorry to exaggerate).

I have had many people tell me that I have to pick a specific architecture for a specific CPU from many reputable sources, but I am then shown code examples that work on several different CPUs... conflicting information!

Helppppppp I am going crazy :p and thank you!
3
The Campus / Re: New recruit
« Last post by Fredelig on Today at 08:40:15 PM »
Thanks for the warm welcome guys, yeah, I'll definitely check out the game developer forum daydreamer  :t

Can't say I'm that skilled yet, but I like programming, I think it's fun, and I've been a computer geek for more than 2 decades, so that's a start :)
4
The Campus / Re: FASTCALL calling convention and MACROS
« Last post by hutch-- on Today at 07:04:17 PM »
Here is an example for you, the identical algorithm with both a stack frame and without. The comments in the disassembly are mine.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    LOCAL retval    :QWORD

    invoke slen1,"1234567890"
    mov retval, rv(slen1,"1234567890")
    conout str$(retval)," invoke call",lf

    .data
      numbers db "1234567890",0
      pnum dq numbers
    .code

    mov retval, rvcall(slen2,pnum)
    conout str$(retval)," register call",lf


    waitkey

    invoke ExitProcess,0

    ret

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

 slen1 proc psrc:QWORD

    mov rax, psrc
    sub rax, 1
  @@:
    add rax, 1
    cmp BYTE PTR [rax], 0
    jnz @B

    sub rax, psrc

    ret

 slen1 endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

 NOSTACKFRAME

 slen2 proc

    mov rax, rcx
    sub rax, 1
  @@:
    add rax, 1
    cmp BYTE PTR [rax], 0
    jnz @B

    sub rax, rcx

    ret

 slen2 endp

 STACKFRAME

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end

 comment #

; --------------------------------------------------------------------------
; sub_1400010d8
; --------------------------------------------------------------------------
sub_1400010d8   proc
.text:00000001400010d8 C8800000                   enter 0x80, 0x0                   ; set up the stack frame
.text:00000001400010dc 4883EC60                   sub rsp, 0x60                     ; set up stack space
.text:00000001400010e0 48894D10                   mov qword ptr [rbp+0x10], rcx     ; write register to shadow space
.text:00000001400010e4 488B4510                   mov rax, qword ptr [rbp+0x10]     ; shadow space variable to register
.text:00000001400010e8 4883E801                   sub rax, 0x1
.text:00000001400010ec
.text:00000001400010ec 0x1400010ec:
.text:00000001400010ec 4883C001                   add rax, 0x1
.text:00000001400010f0 803800                     cmp byte ptr [rax], 0x0
.text:00000001400010f3 75F7                       jne 0x1400010ec
.text:00000001400010f3
.text:00000001400010f5 482B4510                   sub rax, qword ptr [rbp+0x10]     ; sub address in shadow space from rax
.text:00000001400010f9 C9                         leave                             ; clean up after stack frame
.text:00000001400010fa C3                         ret
sub_1400010d8   endp
 
; --------------------------------------------------------------------------
; sub_1400010fb
; --------------------------------------------------------------------------
sub_1400010fb   proc
.text:00000001400010fb 488BC1                     mov rax, rcx
.text:00000001400010fe 4883E801                   sub rax, 0x1
.text:0000000140001102
.text:0000000140001102 0x140001102:
.text:0000000140001102 4883C001                   add rax, 0x1
.text:0000000140001106 803800                     cmp byte ptr [rax], 0x0
.text:0000000140001109 75F7                       jne 0x140001102
.text:0000000140001109
.text:000000014000110b 482BC1                     sub rax, rcx
.text:000000014000110e C3                         ret
sub_1400010fb   endp
 
.text:000000014000110f CC                         int3
; --------------------------------------------------------------------------

 #
5
The Workshop / Re: Int128 in assembler
« Last post by AW on Today at 06:08:57 PM »
Nevertheless you can't do the RDX:RAX thing in VS (if that was your plan) as already explained, so this is strictly assembler.
I know, it is something that can eventually be explored only in Assembler. Not either within the Windows ABI or the System V ABI.
However, I can not visualize a good way to explore it in a ASM only application. Don't be afraid to post a solution if you have it.
6
The Workshop / Re: REAL16 for statistics and Gamma function
« Last post by jj2007 on Today at 05:06:43 PM »
If REAL8 is not enough, try REAL10 - that is the native precision of the FPU. Ten bits of precision more.

We have a dozen threads about REAL16 precision, though. Forum search is here. The available REAL16 libraries are much slower than the FPU, of course.
7
The Campus / Re: FASTCALL calling convention and MACROS
« Last post by hutch-- on Today at 04:26:27 PM »
The macros for both the stackframe and the procedure call that other wrappers call are by no means easy to read, they are large and complex macros but the example I posted for you in the other thread makes it clear that invoke write to both shadow space and the registers, that is why I XORRED the 4 registers to show that the names in the proc head are used which means they come from shadow space. This is why I posted this code in the other thread.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    invoke testproc,150,300,450,600

    waitkey

    .exit

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

 testproc proc arg1:QWORD,arg2:QWORD,arg3:QWORD,arg4:QWORD

  ; clear the 4 registers

    xor rcx, rcx
    xor rdx, rdx
    xor r8, r8
    xor r9, r9

  ; display the values from shadow space

    conout str$(arg1),lf
    conout str$(arg2),lf
    conout str$(arg3),lf
    conout str$(arg4),lf

    ret

 testproc endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end


The piece that you are missing is what MASM does with the input data and where it ends up at the head of the proc.

The first section that you quoted from the CHM help file actually addresses another problem inherent in the FASTCALL convention, the risks of trying to load registers in the first 4 arguments where you risk overwriting a register that is used in the first 4 args.
8
GoAsm / Re: conversion of a "C" struct
« Last post by Yuri on Today at 03:25:53 PM »
It's already converted in the wingdi.h header file.
Code: [Select]
RGBQUAD STRUCT
    rgbBlue DB
    rgbGreen DB
    rgbRed DB
    rgbReserved DB
ENDS

BITMAPINFOHEADER STRUCT
    biSize DD
    biWidth DD
    biHeight DD
    biPlanes DW
    biBitCount DW
    biCompression DD
    biSizeImage DD
    biXPelsPerMeter DD
    biYPelsPerMeter DD
    biClrUsed DD
    biClrImportant DD
ENDS

BITMAPINFO STRUCT
    bmiHeader BITMAPINFOHEADER
    bmiColors RGBQUAD
ENDS
9
The Workshop / REAL16 for statistics and Gamma function
« Last post by bigbadbob on Today at 02:44:37 PM »
I was wondering how to do this in MASM.  It is hard to do this in any language because you have to mask it and do a lot of manipulation.
I also think that it is even harder to convert from BINARY FLOATING POINT to decimal notation as it means converting it to a string.

I have an algorithm for calculating Gamma that is currently written in a high level language.  It does not have an accurate answer in REAL8 (double) because of rounding error.  I think that calculating it in REAL16 will reduce the round off error, because I could later convert the result to REAL8 dropping the inaccurate bits.  Not really sure but I know that this will significantly slow down the calculation.

This Gamma function keeps multiplying until the iteration stopped changing the delta or 100 iterations.
Code: [Select]
        public static double Gamma(double z)
        {
            double factor = 1.0;
            double delta = 1.0;
            for (int n = 1; n <= 100 && delta > 0.0; n++)
            {
                double previous = factor;

                factor *= (1.0 / (1.0 + (z / n))) * Math.Pow((1.0 + (1.0 / n)), z);

                delta = Math.Abs(factor - previous);
            }

            return factor / z;
        }

This Gamma function starts from 0 increments by some small number and stops at a fake value of infinity called approxInfinity.
Code: [Select]
        public static double GammaIntegral(double z, double approxInfinity, double increment)
        {
            double series = 0.0;
            double delta = 1.0;

            for (double x = 0; x <= approxInfinity; x += increment)
            {
                series += (Math.Pow(x, z - 1) * Math.Exp(-x))*increment;
            }

            return series;
        }

I've passed a few numbers for a single value of z.  Up to the first few decimal points they match, but different parameters yield different results.
I believe that the round off error because of not enough bits in the mantissa is part of the problem.
10
The Campus / Re: FASTCALL calling convention and MACROS
« Last post by bigbadbob on Today at 02:25:16 PM »
In the Helpfile masm64.chm we have the following:

Invoke style procedure call automation

Quote
Arguments are passed left to right with the first 4 arguments being written to 4 specific registers, RCX, RDX, R8 and R9, the rest are writtten to a sequence of specific stack locations. With the first four arguments, if you use any of the registers that the first four arguments are written to you risk overwriting an argument. For example if your third argument is RDX, it will be overwritten by the value written to the second register RDX. You can avoid the problem by either using other available registers or writing memory operands instead of registers.

This does not mention using the shadow space.  I believe that it is skipped.

In this help file MasmHelp.exe.
Quote
    The "invoke" series of macros write the first 4 args to shadow
    space as well as the 4 specified registers then writes additional
    args to the correct stack locations. The argument count limit is
    24 arguments in total.

So the 2 help files do not even match.
My disassembly and list file show that although the shadow space is being saved "invoke" and "fn" are not the MACROS that are saving to the shadow space.

I was wondering if the STACKFRAME and the NOSTACKFRAME macros are in control of that.
I think that using STACKFRAME hooks into the PROC somehow, but I have not determined how yet.  If it is enabled the shadow space is copied to.
Pages: [1] 2 3 ... 10