Source on Github, Packages on the site. :thumbsup:
Tested OK with my major sources :thumbsup:
You don't mention any fix for the USE directive errors. :sad:
I made a modification about the uninitialised data warning when applied to to option flat:1
Still considering other options, but I'd never really planned for using flat for anything other than plain bin.
Quote from: johnsa on June 22, 2019, 09:24:32 AM
I made a modification about the uninitialised data warning when applied to to option flat:1
Still considering other options, but I'd never really planned for using flat for anything other than plain bin.
I know, it was pure serendipty :thumbsup: . I was not expecting that as well. :biggrin:
QuoteUASM is written in C. The source is portable and has successfully been tested with Open Watcom, MS VC, GCC and more.
Strange things in tokenize.c (https://github.com/Terraspace/UASM/blob/master/tokenize.c)
like
<<<<<<< HEAD and
'\[' ...
msvc 2003 fails
clang fails
... fails
EDIT: examples:
Windows clang 9
..\UASM-master\codegenv2.c(1170,5): error: conflicting types for 'BuildMemoryEncoding'
int BuildMemoryEncoding(unsigned char* pmodRM, unsigned char* pSIB, unsigned char* pREX, bool* needModRM, bool* needSIB,
^
..\UASM-master\H/codegenv2.h(391,15): note: previous declaration is here
int BuildMemoryEncoding(unsigned char* pmodRM, unsigned char* pSIB, unsigned char* pREX, bool* needRM, bool* needSIB,
...
..\UASM-master\codegenv2.c(1655,55): error: too many arguments to function call, expected 3, have 4
rexByte |= BuildREX(rexByte, matchedInstr, opExpr, FALSE); /* Modify the REX prefix for non-memory operands/sizing */
~~~~~~~~ ^~~~~
...
..\UASM-master\invoke.c(2126,12): error: conflicting types for 'sysv_reg'
static int sysv_reg(struct dsym const* proc, unsigned int reg )
^
..\UASM-master\invoke.c(173,14): note: previous declaration is here
static int sysv_reg ( unsigned int );
^
..\UASM-master\invoke.c(2419,25): error: too many arguments to function call, expected 1, have 2
reg = sysv_reg(proc, reg);
~~~~~~~~ ^~~
Hi johnsa
I was able to compile my sources without problems :thup:
Biterider
Hi Johnsa,
Easy Code 64-bit compiles and works fine! :thup:
Hi TimoVJL
you can remove '\' in those cases: '\[' '\]' '\{' '\}' "\{ and \}"
It will work than with your tools
It is only in tokenize.c
we will also remove it in the next release
there was reason why I was using that, b4 I found why was that needed, now it is not necessary any more
MSVC 2019 had no problem with it
I will be doing some more C compatibility fixes over time, as eventually I am aiming to get it compiling with VBCC. However in the meantime I have no problems compiling it on OSX and Linux using Clang and GCC.
Quote from: johnsa on June 23, 2019, 07:15:58 PM
I will be doing some more C compatibility fixes over time, as eventually I am aiming to get it compiling with VBCC.
vbcc (https://en.m.wikipedia.org/wiki/Vbcc) ?
vbcc (http://www.compilers.de/vbcc.html)
Amiga-Dev (https://github.com/kusma/amiga-dev)
Quote from: johnsa on June 23, 2019, 07:15:58 PM
However in the meantime I have no problems compiling it on OSX and Linux using Clang and GCC.
Windows version of clang 8/9 fails too, but msvc/gcc/clang are just hybrid C/C++ compilers.
clang is a good reference compiler.
EDIT:
vbcc:
don't support anonymous unions in structs
needs linefeed end of included file
Yes.. you might have guessed.. I'd like to be able to run Uasm on my Amiga :)
Once it runs there, I will be looking at building a new set of tokenizer/parser and codegen support for 68k but based on the full UASM code-base.
Devpac is a pretty decent assembler on Amiga, vasm even better with modern support. However they all pale in comparison to a modern x86 Assembly in terms of macros, HLL and features.
Especially interested in adding support for 080/AMMX for the Vampire range of next-gen Amiga accelerators.
I think the movq bug is still there at least when building for 32-bit.
I have also noticed that in 32-bit, C-Style Calling does not appear to support assignment of return values (or may be I am missing something).
Hi AW,
this is what I get using uasm32 or uasm64
movq r11, xmm1
66 49 0F 7E CB movq r11,xmm1
give us some example code for this and for C-Style Calling
Hi Habran,
I attach the case for C-like in 32 bit, which comes out of this thread (http://masm32.com/board/index.php?topic=7928.0) . For example, if you uncomment lines 69 or 77 it produces errors.
Now, I am not able to reproduce the movq bug, I will be back if I do.
This builds OK:
mov rdx, qword ptr [rsp]
printf("Computed sum = %.1f.\n", rdx)
This produces Error A2102: Symbol not defined : qwordptr
printf("Computed sum = %.1f.\n", qword ptr [rsp])
Have two fixes ready for both issues with c-style calls.
I am also changing default arch back to SSE as it should be. It should only be necessary to specify option ARCH:AVX.
I will have a pre-release of 2.50 shortly with these in.
Thank you. :thumbsup:
Quote from: johnsa on June 26, 2019, 09:23:14 PM
Have two fixes ready for both issues with c-style calls.
I am also changing default arch back to SSE as it should be. It should only be necessary to specify option ARCH:AVX.
I will have a pre-release of 2.50 shortly with these in.
Hi johnsa,
I see multiple compilation errors, final fix still awaited?
on 2.50 branch yes, W.I.P :)
Should have all the fixes in tonight/tomorrow.