Index
> Main > flat assembler 1.71.40 |
| Author |
|
|
Tomasz Grysztar 19 Oct 2015, 16:27
This is a new development release that includes the new Intel AVX-512 instructions and few other new extensions from Intel. The added instruction sets follow the Intel reference 319433-023 from August 2015.
Some small changes had to be made in the existing code base and therefore this version requires more testing, to make sure that it doesn't break anything (other than reserving a bunch of new words for the new mnemonics). It took me a long time to prepare it (because my focus has been moved to fasm g instead) and I am releasing it as early as possible, at the price of the increased risk of bugs. In some rare cases the new EVEX encoding introduced by AVX-512 may produce a shorter encoding of AVX/AVX2 instruction than the original VEX one. The new assembly mode setting "useavx512" is introduced to allow fasm to optimize the old AVX/AVX2 instructions this way. The "useavx256" restores the default mode, in which the AVX/AVX2 instructions are always encoded classically. |
|||
19 Oct 2015, 16:27 |
|
|
MIHIP 19 Oct 2015, 16:56
Great release. I will start to searching bugs NOW.
|
|||
|
19 Oct 2015, 16:56 |
|
. Is there a roadmap of any future versions available somewhere?
|
revolution 20 Oct 2015, 11:58
coen wrote: Also I was wondering what the best way is to test AVX-512 instructions since it's currently not available in any processors as far as I know, using the Intel Software Development Emulator or perhaps something else? |
|||
|
20 Oct 2015, 11:58 |
|
|
coen 20 Oct 2015, 13:27
revolution wrote: If you mean testing the assembler output, rather than testing the operation, then a disassembler and/or manually checking the binary would be viable options. |
|||
|
20 Oct 2015, 13:27 |
|
|
revolution 22 Oct 2015, 04:00
I think it is worth mentioning the problem of using some of the new instructions inside of preprocessor blocks (macro/struc/rept/match/irp/irps/irpv/postpone).
Notice in the following example that the closing braces for {k6} and {rd-see} need to be escaped with a backslash to allow assembly. Code: rept 1 { vaddps zmm7 {k6\}, zmm2, zmm4, {rd-sae\} ;<--- the closing braces must be escaped } |
|||
|
22 Oct 2015, 04:00 |
|
|
Tomasz Grysztar 22 Oct 2015, 09:46
Thank you for reminding - this is a detail I planned to mention in initial announcement, but I forgot.
PS 1.71.41 has no separate announcement, because it is it just a very minor bug fix. |
|||
|
22 Oct 2015, 09:46 |
|
|
JohnFound 22 Oct 2015, 13:18
Hm, IMO, these curly brackets in the instruction and the need to escape them, can make problems with some more sophisticated macros.
As long as the curly brackets in FASM are reserved for the preprocessor syntax, isn't it possible to use for example round brackets instead. It will improve the readability of the code and will not cause problems with the macro definitions. |
|||
|
22 Oct 2015, 13:18 |
|
|
l_inc 22 Oct 2015, 13:31
JohnFound wrote: these curly brackets in the instruction and the need to escape them, can make problems with some more sophisticated macros Yes, very likely. Like passing an instruction as an argument of a macro works OK until you put the argument inside of a nested macroblock: Code: macro msg i { macro instruction \{ i \} instruction display 'World',13,10 } msg rept 2 { display 'Hello ' } Unfortunately these curly braces are natural in the ARM instruction architecture and have always been there in the ARM port. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
22 Oct 2015, 13:31 |
|
|
revolution 22 Oct 2015, 14:25
JohnFound wrote: As long as the curly brackets in FASM are reserved for the preprocessor syntax, isn't it possible to use for example round brackets instead. It will improve the readability of the code and will not cause problems with the macro definitions. |
|||
|
22 Oct 2015, 14:25 |
|
|
Tomasz Grysztar 25 Oct 2015, 21:56
coen wrote: I haven't been using FASM very long but good to see that new versions are still being released |
|||
|
25 Oct 2015, 21:56 |
|
|
l_inc 25 Oct 2015, 22:32
Tomasz Grysztar
No binary relocation support should be expected anymore in fasm 1? Seems like you already had a prototype implementation but smth. went wrong. The syntax choice wasn't satisfactory enough? _________________ Faith is a superposition of knowledge and fallacy |
|||
|
25 Oct 2015, 22:32 |
|
|
Tomasz Grysztar 26 Oct 2015, 13:17
I had no real prototype, only the design in my head. It looked nice, because it was going to connect many pieces that already are there in fasm 1, and do it in a simple and straightforward way. But the more I thought about how much more can I squeeze from the fasm 1 engine, the more I realized that I regretted not having tried to make fasm 2. That caused the big shift last year, when I decided to get the new engine going, no matter the price. It came out better than I thought it would - since 2007 I've been abandoning fasm 2 design at least a few times, every time hitting the wall of irreconcilable contradictions in my schemes, but this time I managed to make something that works. But it stole a lot of my time that could otherwise go to fasm 1 development (I previously planned to have AVX-512 ready a year ago), and also stole the most of my attention. But I did not say that no new features like this one will get added into fasm 1 in the future - all I'm saying is "not at the moment".
|
|||
|
26 Oct 2015, 13:17 |
|
|
l_inc 26 Oct 2015, 22:33
Tomasz Grysztar
Quote: But I did not say that no new features like this one will get added into fasm 1 in the future - all I'm saying is "not at the moment". That's good enough for me. Thanks for elaborating. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
26 Oct 2015, 22:33 |
|
< Last Thread | Next Thread > |
Forum Rules:
|