the final weeks of fasm 1.67

Index > Main > the final weeks of fasm 1.67

Goto page 1, 2 Next

Author

Thread

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8349
Location: Kraków, Poland

Tomasz Grysztar 23 Mar 2009, 19:42

Because the first tests of the EFI support in the latest fasm version seem to be successful, the time of 1.68 milestone release becomes more and more near. The only work that is left to do, is updating the documentation (which hasn't been updated in a long time and there is a lot of new stuff to cover), and maybe some bugfixes, if there are any new bugs found. So here comes my request to everyone: please download the latest version and test it, as much as you can.

23 Mar 2009, 19:42

Helle

Joined: 24 Feb 2007
Posts: 23
Location: Germany

Helle 24 Mar 2009, 01:20

Hello,
I have a curious effect: A stand-alone-instruction like
roundps xmm2,dqword[T],1
or other (exist) variable or values or any other instructions gives an "error: invalid size of operand".
With
movaps xmm7,xmm5
or any other float/double/-moves or other registers (also without relation to the next instruction!) is this o.K.

Thanks!
Helle

24 Mar 2009, 01:20

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8349
Location: Kraków, Poland

Tomasz Grysztar 24 Mar 2009, 06:43

Any other instruction? Have you encountered this error with instruction other, than from SSE4? For those it's now fixed.

24 Mar 2009, 06:43

Helle

Joined: 24 Feb 2007
Posts: 23
Location: Germany

Helle 24 Mar 2009, 09:42

Oh sorry, only SSE4. Works fine now!
Thanks!
Helle

24 Mar 2009, 09:42

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8349
Location: Kraków, Poland

Tomasz Grysztar 24 Mar 2009, 12:42

OK, thank you for the report.

24 Mar 2009, 12:42

Mac2004

Joined: 15 Dec 2003
Posts: 314

Mac2004 25 Mar 2009, 03:15

@Thomasz: At least for my projects, Fasm 1.67.37 seems to be working neatly and without any noticeable problems.

Previous DOS version crashing seems to be a thing in the past. Smile

You managed to solve the problem, I think Smile

Regards,
Mac2004

25 Mar 2009, 03:15

Picnic

Joined: 05 May 2007
Posts: 1389
Location: Piraeus, Greece

Picnic 25 Mar 2009, 16:25

Tomasz Grysztar wrote:

please download the latest version and test it, as much as you can.

Thanks for your continuous effort on fasm project Tomasz.
I've download Windows version 1.67.37 and continue working my small projects they work just fine.

25 Mar 2009, 16:25

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 26 Mar 2009, 01:32

Tomasz Grysztar wrote:

if there are any new bugs found. So here comes my request to everyone: please download the latest version and test it, as much as you can.

Regression in the IDE with [F3] see other subforum.

Mac2004 wrote:

Quote:

Fasm 1.67.37 seems to be working neatly and without any noticeable problems. Previous DOS version crashing seems to be a thing in the past. You managed to solve the problem

Again, fixed since 1.67.26 Wink

Code:

version 1.67.26 (Jan 27, 2008)

[+] Added partial SSE4 support (a couple of instructions left to be implemented
    in the next releases)

[+] Added GETSEC instruction for the SMX functions calling.

[-] Some fixes and rearrangements in the DOS version.

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug

26 Mar 2009, 01:32

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8349
Location: Kraków, Poland

Tomasz Grysztar 26 Mar 2009, 08:23

DOS386 wrote:

Tomasz Grysztar wrote:
if there are any new bugs found. So here comes my request to everyone: please download the latest version and test it, as much as you can.
Regression in the IDE with [F3] see other subforum.

I did mean bugs in core, not IDEs, actually. But thanks anyway.

26 Mar 2009, 08:23

Helle

Joined: 24 Feb 2007
Posts: 23
Location: Germany

Helle 28 Mar 2009, 21:12

Hello,
I think the SSE4.1-instructions roundss and roundsd with memory-parameter are not right. Both accept now only 128-bit-memory but not 32-bit (roundss) or 64-bit (roundsd). My tests: roundss load only bit0-bit31 from the memory in the XMM-register (roundsd: bit0-bit63). Right is therefore:
- roundss xmmx, dword(memory),imm8
- roundsd xmmx, qword(memory),imm8.

Thanks!
Helle

28 Mar 2009, 21:12

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8349
Location: Kraków, Poland

Tomasz Grysztar 29 Mar 2009, 10:16

Thanks for another report, it's fixed now.

29 Mar 2009, 10:16

DOS386

Joined: 08 Dec 2006
Posts: 1900

DOS386 30 Mar 2009, 01:19

Code:

version 1.67.38 (Mar 29, 2009)

[-] Fixed a bug with size of memory operand for ROUNDSS/ROUNDSD.


version 1.67.37 (Mar 24, 2009)

[-] The .efi extension is now generated for EFI PE formats.

[-] Fixed a bug with invalid size of memory operand for SSE4 instructions.


version 1.67.36 (Mar 20, 2009)

[-] The size of section table was stored with a wrong value in symbols file,
    it should have the correct value now.

30 Mar 2009, 01:19

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20298
Location: In your JS exploiting you and your system

revolution 30 Mar 2009, 07:27

Tomasz Grysztar wrote:

I did mean bugs in core ...

This bug (from May 2006) still exists:

Code:

use32
a: mov eax,[edx+c-a-5]
b: mov esi,[edx+c-a-5]
c:

error: code cannot be generated.

BUT this is okay:

Code:

use32
a: mov eax,[edx+c-a-5]
   mov esi,[edx+c-a-5]
c:

The only change is the removal of the unused label b.

30 Mar 2009, 07:27

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 31 Mar 2009, 20:04

Tomasz, see this link: http://board.flatassembler.net/topic.php?p=92017#92017

31 Mar 2009, 20:04

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8349
Location: Kraków, Poland

Tomasz Grysztar 31 Mar 2009, 21:17

That would perhaps be correctable by making few "eqtype" checks in "pushd" macro to make sure it allows one parameter only. I'm not sure if it's worth it, though.

In fact, you could even somehow utilize this behavior, for example:

Code:

stdcall some_proc_that_accepts_qword_param, high_dword low_dword

31 Mar 2009, 21:17

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20298
Location: In your JS exploiting you and your system

revolution 01 Apr 2009, 01:26

Tomasz Grysztar wrote:

In fact, you could even somehow utilize this behavior, for example:
Code:
stdcall some_proc_that_accepts_qword_param, high_dword low_dword    

In that case I think it should either be documented or fixed, but not left hanging. Leaving in these gotcha's can be problematic for someone that is not aware, or has not read this particular thread. By right, Azu's code should have generated an error and that would have alerted Azu to the fact that there was a problem. There should always be a comma (,) between parameters unless the user has explicitly stated that they desire a qword stored. This would remove any ambiguity and improve the standing of the assembler macros to give confidence to users that the code generated is what they expected.

BTW: Do you intend to fix the problem I show three posts above? You never said anything and I am not sure what to make of that, perhaps you missed the posting?

01 Apr 2009, 01:26

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8349
Location: Kraków, Poland

Tomasz Grysztar 01 Apr 2009, 04:55

revolution wrote:

This would remove any ambiguity and improve the standing of the assembler macros to give confidence to users that the code generated is what they expected.

I don't think it's possible to really get rid of the problems with macros. They are either simple but have to be properly used, or overcomplex, and still not necessarily reliable. I'm not trying to make them as reliable as the assembler, as this is a futile task.

revolution wrote:

BTW: Do you intend to fix the problem I show three posts above? You never said anything and I am not sure what to make of that, perhaps you missed the posting?

I thought we discussed that in the other thread?

01 Apr 2009, 04:55

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20298
Location: In your JS exploiting you and your system

revolution 01 Apr 2009, 05:20

Tomasz Grysztar wrote:

I thought we discussed that in the other thread?

This is a different problem and it was identified in the other thread but never discussed. The existence of the unused label b causes the assembler to say code cannot be generated. b is not used anywhere but it still manages to affect the ability of the assembler to create the code.

01 Apr 2009, 05:20

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8349
Location: Kraków, Poland

Tomasz Grysztar 01 Apr 2009, 05:35

revolution wrote:

This is a different problem and it was identified in the other thread but never discussed.

That's not true. Read my 11th post from top there.

01 Apr 2009, 05:35

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20298
Location: In your JS exploiting you and your system

revolution 01 Apr 2009, 06:36

Tomasz Grysztar wrote:

revolution wrote:
This is a different problem and it was identified in the other thread but never discussed.

That's not true. Read my 11th post from top there.

Okay, sorry, I didn't realise that you were referring to the label problem in that post. The "As for the second ..." was not clear to me at the time.

01 Apr 2009, 06:36

Goto page 1, 2 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum