Index
> Main > flat assembler 1.69.15+Goto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
bitRAKE 31 Aug 2010, 03:49
|
|||
31 Aug 2010, 03:49 |
|
|
Helle 05 Sep 2010, 09:38
Please take a look at VSTMXCSR; gives an "illegal instruction" (FAsm 1.69.19). Is VLDMXCSR right? (But I´m not sure!)
Thanks! Helle |
|||
|
05 Sep 2010, 09:38 |
|
|
DOS386 06 Sep 2010, 18:53
What's new (67.19 vs 67.16) :
Code: [-] Corrected the calculation of "shr" and "xor" on negative values when the size of value is explicitly stated. [-] Allowed "dup" to be used with zero count. Also other small corrections were made in handling various counts specified to assembler. [+] Added missing "xgetbv" and "xsetbv" instructions. [-] Few small corrections. - subminor typo-fixes in main TFM - updated many outdated (C)'s to 2010 
- fixes in editor core in NAVIGATE.INC and SARCH.INC - crucial updates in DOS IDE - S&R count and not found text reported
- update in DOS IDE - added and documented "Alt+Delete discard undo information (frees some memory)" - update in DOS IDE - replaced "16" by "SEGMENT_HEADER_LENGTH" almost 1'000'000 times See shots: 
Old and new texts are not included but amount is so the "pushed-CTL-H-instead-CTL-F-BUG" is fairly well fixed
 |
|||
|
06 Sep 2010, 18:53 |
|
|
DOS386 06 Sep 2010, 20:50
Code: version 1.69.20 (Sep 06, 2010) [+] Added missing "vstmxcsr", "xsave", "xrstor" instructions. - increased bloat by cca 40 Byte's - better security checks in EXPRPARS.INC ??? |
|||
|
06 Sep 2010, 20:50 |
|
|
Helle 08 Sep 2010, 18:21
Sorry if this is an older bug, but I had today this problem: PEXTRQ Reg64,XMMx,Imm8 is right with REX.W, but PEXTRQ Mem64,XMMx,Imm8 is without REX.W and the result is PEXTRD.
Please take a look. Thanks! Helle |
|||
|
08 Sep 2010, 18:21 |
|
|
Tomasz Grysztar 08 Sep 2010, 18:34
Fixed in 1.69.21 (the sub-minor version number got a high speed recently...).
|
|||
|
08 Sep 2010, 18:34 |
|
|
Tomasz Grysztar 08 Sep 2010, 19:16
I also finished the rare [ds:ebp+ebp+disp32] optimization in 1.69.21 - this is something I started some time ago but then I forgot and it was left in unfinished state, which actually caused it to generate even less optimal code than before. But it is all corrected now.
The optimization works like this: Code: 00000000: 3E FF 44 2D 7F inc dword [ds:ebp+ebp+7Fh] 00000005: FF 04 6D 80 00 00 00 inc dword [ds:ebp+ebp+80h] Same optimization happens when you write "ebp*2" instead of "ebp+ebp", etc. |
|||
|
08 Sep 2010, 19:16 |
|
|
DOS386 09 Sep 2010, 06:12
Code: version 1.69.21 (Sep 08, 2010) [-] Corrected encoding of "pextrq" instruction with memory operand. And the other one (documented here above only) done in EXPRCALC.INC |
|||
|
09 Sep 2010, 06:12 |
|
|
Tomasz Grysztar 09 Sep 2010, 08:04
I re-uploaded it with a few more small corrections. The meaningless segment prefixes are no longer generated in long mode (unless you use them in mnemonic form) - this also counts as an improvement in size optimization.
|
|||
|
09 Sep 2010, 08:04 |
|
|
edemko 09 Sep 2010, 11:18
Tomasz, add "whatnew.txt" etc link on upload page.
|
|||
|
09 Sep 2010, 11:18 |
|
|
Tomasz Grysztar 09 Sep 2010, 18:20
As the 1.69.22 is now interpreting the formatter symbols only in the context of format/section/segment/data directives, and therefore adding new formatter keywords does not limit the reservoir of words allowed as labels, I am now less reluctant to introduce new formatter keyword, even in large number, if that was needed for some reason.
The first one I'd like to add is the flag for Large Address Aware setting in 32-bit PE. I proposed the name "largeaddr", also "largeaddress" is the other possibility. If anyone has any suggestions regarding this, please let me know. |
|||
|
09 Sep 2010, 18:20 |
|
|
Tomasz Grysztar 09 Sep 2010, 18:21
edemko wrote: Tomasz, add "whatnew.txt" etc link on upload page. |
|||
|
09 Sep 2010, 18:21 |
|
|
MHajduk 09 Sep 2010, 19:17
Tomasz Grysztar wrote: The first one I'd like to add is the flag for Large Address Aware setting in 32-bit PE. I proposed the name "largeaddr", also "largeaddress" is the other possibility. If anyone has any suggestions regarding this, please let me know.
 |
|||
|
09 Sep 2010, 19:17 |
|
|
rugxulo 09 Sep 2010, 19:53
If the word doesn't clash in program namespace, how about just use "large"?? Or is this truly only useful for PAE/3GB? "largeflag" or "largesize" seem more sensible to me than "largeaddr" (no vowel clash). But it honestly doesn't matter as long as it's documented (and we never did ever agree over "branch taken / not taken" mnemonics).
|
|||
|
09 Sep 2010, 19:53 |
|
|
Tomasz Grysztar 09 Sep 2010, 21:18
rugxulo wrote: If the word doesn't clash in program namespace, how about just use "large"?? rugxulo wrote: Or is this truly only useful for PAE/3GB? This flag is useful not only for Win32 with 3GB adressing, but also when you execute 32-bit program in 64-bit Windows - it can use the whole 4GB addressing space then. rugxulo wrote: (and we never did ever agree over "branch taken / not taken" mnemonics).  I've left defining some own variants with "equ" up to everyone's personal choice. |
|||
|
09 Sep 2010, 21:18 |
|
|
vid 09 Sep 2010, 21:33
I like "largeaware". IMO the nice short common word "large" for such exotic feature is a waste.
|
|||
|
09 Sep 2010, 21:33 |
|
|
Tomasz Grysztar 09 Sep 2010, 21:35
The point is that we no longer have to worry about wasting the word, because since 1.69.22 the formatter-specific symbols are recognized only in the context of "format" and similar directives. You would still be able to use "large" as a label, for example.
|
|||
|
09 Sep 2010, 21:35 |
|
|
vid 10 Sep 2010, 08:15
allright then
|
|||
|
10 Sep 2010, 08:15 |
|
|
edemko 15 Sep 2010, 07:35
dt 0e32769 dt 0e32770 |
|||
|
15 Sep 2010, 07:35 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|