12 June 2024, 10:23 | #21 | |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,806
|
Quote:
I think I can work with that macro workaround you provided above, my friend... Thanks for that... |
|
24 June 2024, 01:17 | #22 |
Registered User
Join Date: Jul 2018
Location: Laughingstock
Age: 45
Posts: 31
|
Code:
org 100h start: mov $9,%ah mov $hello,%dx int $0x21 ret hello: db "Hello World",13,10,'$' Code:
$ vasmx86_oldstyle -Fbin -m8086 hello.asm -o hello.com Code:
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 |
24 June 2024, 11:16 | #23 |
Registered User
Join Date: Jul 2018
Location: Laughingstock
Age: 45
Posts: 31
|
in cpu.c:
Code:
//static enum codetype mode_flag = CODE_32BIT; /* 32 bit is default */ static enum codetype mode_flag = CODE_16BIT; |
24 June 2024, 11:37 | #24 |
Registered User
Join Date: Jul 2018
Location: Laughingstock
Age: 45
Posts: 31
|
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. |
24 June 2024, 18:21 | #25 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
Quote:
mode_flagshould 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. |
|
24 June 2024, 19:05 | #26 |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,310
|
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) |
24 June 2024, 22:31 | #27 |
Registered User
Join Date: Jul 2018
Location: Laughingstock
Age: 45
Posts: 31
|
@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 |
25 June 2024, 01:03 | #28 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
Quote:
Thanks! Fixed and committed. Will be included in the next daily source snapshot in a few hours. Quote:
|
||
25 June 2024, 21:16 | #29 |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 277
|
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.Win32has 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 Code:
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 Makefile.Win32to remove _win32from line 6 TARGET = 5. nmake /f Makefile.Win32 CPU=m68k SYNTAX=mot 6. Success I don't think separate .Win32and .Win64/ .x64Makefiles are required - the same makefile should be usable from any of the 4 combinations of {host32,host64}x{target32,target64} toolchain. Last edited by hop; 25 June 2024 at 21:18. Reason: Formatting |
25 June 2024, 22:32 | #30 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
Ok... you may be right. When using Visual Studio on Windows, then you are compiling for your native host platform, so the
TARGETextension can be removed and the existing objdirectory can be used, in the same manner as with the default Unix Makefile. Changed and committed for tomorrow's source snapshot. Quote:
.Win64nor .x64Makefile or target. And we have no plans to change that. |
|
26 June 2024, 19:26 | #31 | |
Registered User
Join Date: Apr 2019
Location: UK
Posts: 277
|
Quote:
|
|
07 July 2024, 03:43 | #32 |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 418
|
The attached example produces negative line numbers in the DWARF output.
Code:
vasmm68k_mot -m68000 -Felf -dwarf=3 -x -o test.o test.s objdump -W test.o [..] Line Number Statements: [0x00000028] Extended opcode 2: set Address to 0 [0x0000002f] Advance Line by -64 to -63 Ah, I think is the problem: Code:
3. DW_LNS_advance_line The DW_LNS_advance_line opcode takes a single signed LEB128 operand and adds that value to the line register of the state machine. Code:
add_data_atom(dinfo->lsec,1,1,DW_LNS_advance_line); add_leb128_atom(dinfo->lsec,line-dinfo->line); Last edited by arcanist; 07 July 2024 at 03:57. |
07 July 2024, 09:18 | #33 |
Zone Friend
Join Date: May 2006
Location: France
Posts: 1,894
|
Reduce assembling time as much as possible on native Amiga.
|
20 July 2024, 16:09 | #34 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
|
20 July 2024, 16:33 | #35 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
Yes, improving performance is always on my list, although not highest priority, because vasm is primarily a cross-assembler. I know that using it on real Amiga hardware with less than 68030 or 68040 is a pain. And the extreme memory requirements can easily be a K.O. criterium on smaller systems. Other assemblers may be better suited for native assembly.
The memory requirements can be reduced by compiling with -DLOWMEM. This will minimize the size of all hash-tables (which doesn't improve performance, as you might guess). Also you may want to add only those output-modules you really need. For example: -DOUTBIN -DOUTHUNK. To improve performance I would have to do some profiling on real hardware again. I cannot promise to do that before 2.0, though. |
20 July 2024, 17:10 | #36 | |
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 549
|
Quote:
You assembler can output X68000 .X executable files directly but is there a way to specify the entry point which can be different from the code section loading address (i didn't find any) ? Also there are 3 kind of executable files on this machine, the .X that you've covered already, the .R which are raw files without any ornaments (think MS-DOS .com but without any fixed loading address) and the .Z which are absolute address executable files using a shorter header and (obviously) no relocation infos, that header looks like this: Code:
struct x68_z_header { unsigned short magic; // 0x601a unsigned long code; unsigned long data; unsigned long bss; unsigned char reserved[8]; unsigned long base; unsigned short padding; } __attribute__ ((packed)); // 28/0x1c bytes |
|
20 July 2024, 19:30 | #37 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
Quote:
-startoffs=option in output_xfile.c, but it is commented out - probably because I never understood how it works. I noticed you are the author of x68k2amiga? Most of the information for writing the XFile output I got from your source. Thanks again! Then you are probably one of the few experts who can help me to improve the output format!
Quote:
-Fbin)? Quote:
Code and data follow the header in one contiguous block? Any alignment between the sections, in case the size in the header is odd? I assume the BSS section is included in the file? |
|||
21 July 2024, 01:02 | #38 | |||
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 549
|
Quote:
The base is a negative offset that is subtracted from the entry point value (so basically if the base is $50, the entry point will be *at least* $50 as well), i never seen it being used anywhere. The only loading modes that seem to be relevant are the normal mode (0) and the high address (2) mode, in that mode the executable files are loaded at the top of the memory (stuff like MS-DOS's HIMEM) instead of the lower addresses. Quote:
Quote:
The BSS block is not included inside the file. |
|||
21 July 2024, 15:53 | #39 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,577
|
Ok. New option is
-exec=<label>, where <label>defines the entry-label of the program. Omitting this option will default to the code section's base address. Quote:
-loadhigh. You find all new features in tomorrow's source snapshot: http://sun.hasenbraten.de/vasm/daily/vasm.tar.gz Quote:
Is that really an official executable format, loadable from the OS (Human68k) or the command line? The similarity to the Atari TOS executable header makes me suspicious. How does it work? Using the SHARP assembler, you would write your normal (relocatable) code, data and bss sections, but pass the absolute address for the z_header as an option to the assembler or the linker? I'm asking, because usually you would just write an ORGdirective with the absolute address in such a case. |
||
21 July 2024, 16:46 | #40 | |
Registered User
Join Date: Jun 2008
Location: somewhere else
Posts: 549
|
Quote:
Several games used them, mostly as subsidiary executables (like 'Dragon Slayer - The Legend of Heroes (Eiyuu Densetsu)" by Falcom which consists of 340 of such files). There's a small catch, the last padding word of the header can't be 0 or the OS will reject it, any other value will do. I don't know which tool is used to create them. I guess from a linker or from an assembler with a origin address argument. Here's a small hand crafted .z which the OS will happily run at address $100000: https://hitchhikr.net/test.z |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Vasm | freehand | Coders. Asm / Hardware | 2 | 25 November 2023 23:51 |
Question about XREF vs XDEF (vasm 1.8 vs vasm 1.9) | roondar | Coders. Asm / Hardware | 8 | 01 May 2023 20:59 |
Vasm division by 0 | Quagliarulo | Coders. Asm / Hardware | 4 | 27 July 2020 11:30 |
If statements with Vasm | LaBodilsen | Coders. Asm / Hardware | 5 | 24 September 2019 17:55 |
vasm 1.5 RFC | phx | Coders. General | 30 | 11 December 2010 02:08 |
|
|