vasm 2.0

[Tigerskunk]

Originally Posted by phx

The std-syntax module provides the

.irp

directive for "iterating repeat". You can specifiy some values which will be assigned to a symbol:

        .irp    sym,10,20,30,40
lab\sym:
        .byte   \sym
        .endr

Maybe I can implement an

IRP

directive into mot-syntax, if this is useful. (Although I don't like to invent new directives, which make vasm incompatible with other assemblers.)

No, everything fine...
I think I can work with that macro workaround you provided above, my friend...

Thanks for that...

[frakswe]

   
org 100h

start:

    mov $9,%ah
    mov $hello,%dx
    int $0x21
    ret

hello:
    db "Hello World",13,10,'$'

$ vasmx86_oldstyle -Fbin -m8086 hello.asm -o hello.com

0000000000000000 b409             mov ah, 0x9             
0000000000000002 66ba0901cd21     mov edx, 0x21cd0109     
0000000000000008 c3               ret                     
0000000000000009 48               dec ax                  
000000000000000a 656c             gs insb                 
000000000000000c 6c               insb                    
000000000000000d 6f               invalid                 
000000000000000e 20576f           and [bx+0x6f], dl       
0000000000000011 726c             jb 0x7f                 
0000000000000013 640d0a24         or ax, 0x240a

dx becomes edx , is this a limitation of the x86 module?

[frakswe]

in cpu.c:

//static enum codetype mode_flag = CODE_32BIT;  /* 32 bit is default */
static enum codetype mode_flag = CODE_16BIT;

did the trick, although not a proper fix ofcourse.

[frakswe]

ok the directive code16 also works. guess it's down to why -m8086 doesn't limit the opcodes then.

but i'll let you figure that one out.

[phx]

Originally Posted by frakswe

ok the directive code16 also works. guess it's down to why -m8086 doesn't limit the opcodes then.

Looks like

mode_flag

should be set to a sensible mode, according to the selected CPU. I wrote this backend 20 years ago and never really touched it again, so I don't remember why I chose not to do that.

What do you think which default mode make sense for which CPU? Besides writing this backend my experience with x86 is close to zero.

And you may also contact me by email, as this is possibly the wrong forum for discussing vasmx86.

[paraj]

Just one final note on vasmx86 (that I haven't used before), and not to knock on phx's good work in general there, but it's probably not well tested for <386 targets. In particular it won't error out on non-short Jcc's, but will instead emit the 386+ disp16/32 variant (0F 8x) even for -m8086. Likely won't be a problem if you're trying to make existing code work, but if you're trying to make something new targeting actual 8086 you need to be aware of it.

(Happy to continue discussion elsewhere)

[frakswe]

@phx
8086,186,286 - code16
386-686 - code32
amd64 - code64

https://en.wikipedia.org/wiki/X86

and why can't we discuss x86 here? aros is a thing :P

[phx]

Originally Posted by paraj

it's probably not well tested for <386 targets. In particular it won't error out on non-short Jcc's, but will instead emit the 386+ disp16/32 variant (0F 8x) even for -m8086.

Indeed, I doubt it was tested at all with this configuration (see below). I may fix that before the 2.0 release, but I fear there are multiple issues of this kind, and it needs some intensive testing.

Originally Posted by frakswe

8086,186,286 - code16
386-686 - code32
amd64 - code64

Thanks! Fixed and committed. Will be included in the next daily source snapshot in a few hours.

and why can't we discuss x86 here? aros is a thing :P

In fact AROS was the only reason I wrote this backend 20 years ago. But it was only ever tested with the code generator of vbcci386 on some simple AROS test code - until all work on the i386-aros vbcc target was stopped. Unfortunately the AROS team decided early to lock their SDK to the gcc compiler and had no plans to make it portable.

[hop]

For release 2.0 it would be great if the Makefiles could be updated so vasm can be built for/on Windows x64 with Visual Studio command line with no changes. Currently

Makefile.Win32

has to be manually edited to build sucessfully.

After downloading the latest snapshot, my process is:
1. Open Visual Studio 2022 x64 Native tools command prompt
2. CD to vasm dir
3.

nmake /f Makefile.Win32 CPU=m68k SYNTAX=mot

c:\Amiga\vasm\vasm.c : fatal error C1083: Cannot open compiler generated file: 'c:\Amiga\vasm\obj_win32\m68k_mot_vasm.o': No such file or directory

4. Edit

Makefile.Win32

to remove

_win32

from line 6

TARGET =

5.

nmake /f Makefile.Win32 CPU=m68k SYNTAX=mot

6. Success

I don't think separate

.Win32

and

.Win64

/

.x64

Makefiles are required - the same makefile should be usable from any of the 4 combinations of {host32,host64}x{target32,target64} toolchain.

[phx]

Originally Posted by hop

4. Edit

Makefile.Win32

to remove

_win32

from line 6

TARGET =

Ok... you may be right. When using Visual Studio on Windows, then you are compiling for your native host platform, so the

TARGET

extension can be removed and the existing

obj

directory can be used, in the same manner as with the default Unix Makefile.
Changed and committed for tomorrow's source snapshot.

I don't think separate

.Win32

and

.Win64

/

.x64

Makefiles are required - the same makefile should be usable from any of the 4 combinations of {host32,host64}x{target32,target64} toolchain.

I don't understand. There is neither a

.Win64

nor

.x64

Makefile or target. And we have no plans to change that.