assembler label problem and work on MPIR #330
Comments
|
ok there are four problems - I'm mostly writing this now so you will be aware of #4...
|
|
|
have not yet gotten traction on this... maybe this week |
|
i'm starting to look at this... the .globl problem is probably due to the .type statement, so I guess a part of getting the end result we want has got to be to completely address #236 as well... |
8-| As there's a lot of code out there that actually is using gas I think it is worth the work. |
|
sorry for the delay on this and the other things you've brought up recently... I've been dealing with a lot of unexpected compiler bugs that surfaced when I replaced pointers with 'unique_ptr'. To get the unique_ptr to work I had to fix a few bugs and it kind of snowballed on me... fix for one bug broke three other things sigh. I was trying to work it as a background task on another branch but the code diverged so much i decided to just get it finished. As of tonite I have the compiler compiling itself again well enough that it can compile other programs... but there is a problem with one of the more problematic programs in the test suite just hanging when I run it. I Hope to have any remaining problems worked out within the next few days and get back to working on the issues again. |
|
Good to read you make progress.
There's no nneed to push it, take your time.
|
|
thanks! FWIW now I've apparently found some arcane bug in mingw64 that doesn't exist in any of the other compilers, including orange C. Guess I will work on finding a workaround tomorrow... |
|
mingw64 bug? That might be because you don't have the latest compiler version (GCC 7.2 or 8 should be available)? If it's up to date and still buggy, I recommend reporting it because it should be just a straight GCC ontop of an emulation layer... |
|
thanks for the tip. That helped. 8.10 seems to fix it; Previously I had 7.30. |
|
i'm gonna backtrack on that. Seems to work with the i686 builds of mingw64 but not with the x86_64 builds. Unfortunately we need the latter for appveyor... so I guess there has to be a workaround at minimum but if I can get that far I'll also report it. |
|
mea culpa, mingw works fine. There was a longstanding problem that just became uncovered for reasons unknown. If orangec was compiled with a 64 bit compiler it then wouldn't emit exception information properly. Will release a fix for that soon... |
|
I haven't forgotten this... I'm going to work on #355 for a a while then I will come back to it :) |
LADSoft
added this to the #2 assembler: AT&T syntax and Compiler: infrastructure updates milestone
|
@GitMensch question for you, in the opening post of this issue some source code was given that doesn't compile. the GAS documentation says that instruction size should be postfixed on the instruction, e.g.
but the example doesn't use the size postfix values. So I'm wondering what the rules for omitting them are. If omitted does the size default to DWORD? Or is the size derived from the register sizes |
|
never mind I found it in the documentation 😄 |
|
I'm going to check in a fix for this tonite or tomorrow; but it only addresses the mnemonic/operand problems and related issues. The problem of GAS-like directives will be fixed in relation to #236 (also in this milestone) |
|
Rechecked with the merge of assembler branch CI build, does not work: .text
.align 4, 0x90
.globl ___gmpn_add_err1_n
.type ___gmpn_add_err1_n,@function
___gmpn_add_err1_n:
mov 8(%rsp), %rax
push %rbx
push %rbp
push %r12
xor %rbx, %rbx
xor %rbp, %rbp
lea (%rdi,%r9,8), %rdi
lea (%rsi,%r9,8), %rsi
lea (%rdx,%r9,8), %rdx
test $1, %r9
jnz Lodd
Leven:
lea -8(%r8,%r9,8), %r8
neg %r9
jmp Ltop
.align 4, 0x90
Lodd:
lea -16(%r8,%r9,8), %r8
neg %r9
shr $1, %rax
mov (%rsi,%r9,8), %r12
adc (%rdx,%r9,8), %r12
cmovc 8(%r8), %rbx
mov %r12, (%rdi,%r9,8)
setc %al
inc %r9
jz Lend
.align 4, 0x90
Ltop:
mov (%rsi,%r9,8), %r12
shr $1, %rax
adc (%rdx,%r9,8), %r12
mov $0, %r11
mov %r12, (%rdi,%r9,8)
mov $0, %r10
mov 8(%rsi,%r9,8), %r12
cmovc (%r8), %r10
adc 8(%rdx,%r9,8), %r12
cmovc -8(%r8), %r11
setc %al
add %r10, %rbx
adc $0, %rbp
add %r11, %rbx
mov %r12, 8(%rdi,%r9,8)
adc $0, %rbp
add $2, %r9
lea -16(%r8), %r8
jnz Ltop
Lend:
mov %rbx, (%rcx)
mov %rbp, 8(%rcx)
pop %r12
pop %rbp
pop %rbx
ret
Resulting in
Or is this related to the GAS-like directives issue? |
|
this is a problem with not supporting the gas-like directives, but I'll reopen this until it actually compiles your code snippet... |
|
Hi @GitMensch, i fixed this so it will assemble your example now. There may also have been some confusion; you additionally need to specify the command line option --gas:
This was listed in the command line help already but I've updated the .MD files as well now. Note that I had additionally addressed #249 in this milestone, which allows for 'long' names to be used in switches as we move forward. |
|
the problem is a file in mpn\generic. looks like some problem with the configure script. from build_occ\config.h: so ieee_double_extract isn't getting defined from gmp-impl.h. the build for VC seems to have the little endian one defined and I think OCC should too. Will see if I can figure out why the config script fails in this regard but may need help... |
|
ok I think the problem may be that the configure scripts assume the object files are binary in nature and are getting thrown for a loop by the fact the the OCC object files are ascii. meanwhile I tried #defining the little endian one in config.h but still couldn't get past this... |
|
i figured out what I was doing wrong in config.h and it at least compiles everything in the MPN directory now. Then I had to add 'AR=olib' and regenerate the configuration... right now it is failing on the library insert I think because some of the object files are being generated in what appears to be COFF format... I think that is possibly because the project uses YASM? |
|
there is some problem with occ... if I compile occ with MSVC it then compiles the mpn directory, but if I then compile it with itself I then get errors when compiling the mpn directory e.g. in gmp-impl.h. Will fix soon... BTW if the HAVE_DOUBLE_IEEE_LITTLE_ENDIAN detection and similar things that parse a binary formatted object file is a big deal it looks like I have already written a 'binary' version of the object file handling, but it is probably out of date and needs to be vetted further before it can be used... |
Sounds good. So I'll wait until I hear something again (but effectively I'll just do the steps above and when those work run
For now the effect should only be that MPIR will do "normal" double/float handling and no binary optimizations.
Interesting. I think it would be reasonable to handle this with a new issue. It will be interesting to see if/what the effect in case of necessary compile/link time (and object file's size) this has. |
|
ok so there is some problem with attribute((noreturn)) in versions compiled with itself but for now it seems you can get around it by making sure to autoconfigure against the version of the compiler you intend to use. Autoconfigure apparently detects it isn't going to work and causes the compile not to use it. I will fix it tomorrow... MPIR won't compile if you don't have one of the HAVE_DOUBLE flags set. In that case it doesn't define a needed union, so the compile throws errors. I've been assuming we need to get one defined and the way to get one defined is to switch to a binary object file format and then the autoconfig will detect floating point. I'm with you, the binary object format needs a new issue... FWIW I originally wrote that in hopes it will speed things up but didn't see much happening and then decided not to finish it out. That was back when the compiler had an independent version of the object file format handling though. Maybe with the longer builds we will see something... it should cut the files size by quite a bit because right now every literal byte of data is encoded as two ASCII characters... That won't fix everything though, use of YASM pretty much dictates it won't link. And meanwhile 'omake check' is faililng, it doesn't know how to create ../libmpir.la. Will pick it up tomorrow 😄 |
|
I think there's a "slightly" topic drift here ;-)
If this is the case then it is a MPIR bug, which is possible as most (all other?) compilers have a binary format. The solution is not to have a binary object format but to create and apply a minimal patch to the MPIR code - and/or to check if https://github.com/wbhart/mpir already contains the fix - you can get artifacts for it from https://ci.appveyor.com/project/wbhart/mpir (ignore the bad version number 3.0.0 it is up-to-date) |
|
I fixed the noreturn problem. It was much deeper than I first suspected, I'm surprised the compiler worked as well as it did... |
|
the config scripts assume MSVC when it isn't one of the GCC variants, and want to use LIB.EXE. There is even a line in there that says something to the effect of ,FIXME, WE REALLY SHOULD LET THE USER SPECIFY THE LIBRARIAN., a more serious issue is that YASM creates object files the occ toolchain cannot process, so even if I run the librarian separately I get a bunch of errors about object files having a bad format. edited... I looked at the 'omake check' issue and it seems like it may need the build to succeed before it will work. Is that correct? |
|
For config scripts: just workaround as with GnuCOBOL: directly after configure adjust the generated libtool file to use correct librarian.
For yasm: no idea without a computer at hand ;-)
|
|
what I'm getting from configure is assembly language files that cannot be processed by oasm in either mode; hence YASM. But if we need YASM to create object files it just isn't going to work. |
|
I was thinking, if there is some way to get autoconfig to generate gas-compatible assembly language files from the existing stubs, then we wouldn't need YASM and we could also test the oasm GAS compatibility some more. But I haven't a clue as to whether it is even possible, or how to go about it if it is... |
|
You may want to ask on the mpir mailing list if there's any option to not use yasm on x86/64 (it isn't used for other cpus).
|
|
i asked and according to the author of MPIR it can't use GAS. yasm is a requirement at the moment as the MPIR code uses features specific to yasm. there have been proposals to rewrite the assembly code for GAS but noone has found the time to do it. I've gone as far as I can with MPIR. |
|
I think there is at least one thing to do here as there is one assembler related error with MPIR (and a bunch of asserts) [I don't expect the result to "work" any more because of the yasm+linking isuse]. Things to do: setup system (using current "MINGW64, then static lib") as noted above. Shown assembler issues (just reran Syntax errors: Current assert (3 times): Note: one could either ignore the error messages that result from the missing MPIR structure definition or adjust gmp-impl.h to always use the little-endian definition (which I've locally did with changing the |
|
now it compiles a bunch of stuff; when it gets to DOCs it does this:
|
|
As noted this should not happen, and may be an |
LADSoft
changed the title
|
the only reason i was holding this open is because of my comment that the docs wouldn't build for mpir, and the resulting comment from @GitMensch that maybe there was a bug in omake. I was able to verify tonite that right now the mpir docs directory does compile. I think at some point I figured out how to install makeinfo? The rest of the project compiles right up to the point where it tries to link the DLL. Since this is likely due to the usage of yasm I'm going to close this. |
The following assembler constructs don't compile (generated by MPIR [configure and make otherwise works] but most of the assembler sources look that way so all sub-directories fail to be generated):
Complete file (don't ask me why there are so much empty lines in it...):
tmp-add_err1_n.s
The text was updated successfully, but these errors were encountered: