Author Topic: OS/4 (technical details only)  (Read 156476 times)

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #135 on: March 12, 2019, 06:48:16 am »
I tried it and it still traps. 

Dave

It is again  wrongly aligned   ff_cos_32 (fft_template.c  Line 127):
Code: [Select]
vmovaps ymm0, yword [_ff_cos_32]
fft.asm      Line 182

Problem is definitely in GCC  -   no questions to nasm so far.

You can try  to change compilation options to GCC  and check alignment of  _ff_cos_32  in map file to understand if  it is aligned 32.


Upd:

What is object file format  when you compile  .c files  by GCC ?   
« Last Edit: March 12, 2019, 11:48:10 am by OS4User »

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #136 on: March 12, 2019, 09:59:59 am »
Hey Dave,

OK, this is frustrating, especially with my not having AVX hardware. For now just disabling AVX seems the simplest.
Thanks for testing

http://www.voidcn.com/article/p-vtipwtsk-cu.html might be worth a read....

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #137 on: March 12, 2019, 05:18:51 pm »
Hey Dave,

OK, this is frustrating, especially with my not having AVX hardware. For now just disabling AVX seems the simplest.
Thanks for testing

http://www.voidcn.com/article/p-vtipwtsk-cu.html might be worth a read....

Hi Dave,

Pls add -fno-common  to gcc command line  and show   avcode57.map
On simple test  this option shows good result  -  all vars in obj aligned ok.
Alignment between  obj files  is still a question mark.
 

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #138 on: March 12, 2019, 06:05:51 pm »
OK, -fno-common seems to have fixed the alignment, from the map file,
Code: [Select]
Module: K:\work\ffmpeg\src\ffmpeg.obj\libavcodec\fft_fixed.o(src\libavcodec\fft_fixed.c)
0001:001fbc83  _ff_init_ff_cos_tabs_fixed
0001:001fc050  _ff_cos_tabs_fixed
0001:001fbd3c  _ff_fft_init_fixed
0001:001fbf90  _ff_fft_end_fixed
0002:001cc900  _ff_cos_131072_fixed
0002:0020c8e0  _ff_cos_16_fixed
0002:0020c8c0  _ff_cos_32_fixed
0002:0020c880  _ff_cos_64_fixed
0002:0020c800  _ff_cos_128_fixed
0002:0020c700  _ff_cos_256_fixed
0002:0020c500  _ff_cos_512_fixed
0002:0020c100  _ff_cos_1024_fixed
0002:0020b900  _ff_cos_2048_fixed
0002:0020a900  _ff_cos_4096_fixed
0002:00208900  _ff_cos_8192_fixed
0002:00204900  _ff_cos_16384_fixed
0002:001fc900  _ff_cos_32768_fixed
0002:001ec900  _ff_cos_65536_fixed
...
Code: [Select]
Module: K:\work\ffmpeg\src\ffmpeg.obj\libavcodec\fft_float.o(src\libavcodec\fft_float.c)
0001:002114e0  _ff_init_ff_cos_tabs
0001:00211870  _ff_cos_tabs
0001:00211561  _ff_fft_init
0001:002117bc  _ff_fft_end
0002:0020c900  _ff_cos_131072
0002:0028c8c0  _ff_cos_16
0002:0028c880  _ff_cos_32
0002:0028c800  _ff_cos_64
...

Edit, BTW, GCC outputs aout
« Last Edit: March 12, 2019, 06:34:32 pm by Dave Yeo »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #139 on: March 12, 2019, 06:27:48 pm »
New lib package uploaded. It also contains the map files. David, can you test? Thanks

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #140 on: March 12, 2019, 08:58:51 pm »
New lib package uploaded. It also contains the map files. David, can you test? Thanks

Success!!!!!!!!!! So far no crashes at the problem sites.  I will continue to test, but so far everything looks good. 

Paul Smedley

  • Hero Member
  • *****
  • Posts: 2092
  • Karma: +159/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #141 on: March 13, 2019, 02:57:58 am »
New lib package uploaded. It also contains the map files. David, can you test? Thanks

Success!!!!!!!!!! So far no crashes at the problem sites.  I will continue to test, but so far everything looks good.

Cool, this might help me find how to fix this more correctly within GCC. From what I've read, it was fixed for mingw back in GCC 4.4.0 timeframe - so I should hopefully be able to track down what they changed.

Cheers,

Paul

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #142 on: March 13, 2019, 05:47:24 am »
I ran the test suite (FATE) and seemed to have the same errors as previously, though that was with static libs. I do note that the article says this,
Quote
but it can not work in the sharing mode of FFMPEG in the current official release.
Though compiling with --enable-shared worked fine here.

I've also created a ticket at netlabs, http://trac.netlabs.org/ports/ticket/206

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #143 on: March 14, 2019, 06:12:14 pm »
I ran the test suite (FATE) and seemed to have the same errors as previously, though that was with static libs. I do note that the article says this,
Quote
but it can not work in the sharing mode of FFMPEG in the current official release.
Though compiling with --enable-shared worked fine here.

I've also created a ticket at netlabs, http://trac.netlabs.org/ports/ticket/206

Dave, I have been using now for a few days.  Not one crash.  Working great.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #144 on: March 14, 2019, 06:26:41 pm »
Dave, I have been using now for a few days.  Not one crash.  Working great.

David,

It is because you have a good karma  :)   We cannot expect  always  positive result with current  GCC.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #145 on: March 14, 2019, 07:55:46 pm »
I think it is limitations of the aout format. At one point there were plans to switch GCC to outputting ELF and converting that to OMF. Unluckily I can't see that ever happening with current manpower.
Another option would be switching to Win32 output, probably be a lot easier, especially if wlink can take win32 object files and output OS/2 executables, but even that'll likely never happen.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #146 on: March 14, 2019, 08:05:06 pm »
I think it is limitations of the aout format. At one point there were plans to switch GCC to outputting ELF and converting that to OMF

AFAIK no need to convert ELF  to OMF    -  wl can link ELF to  LX

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #147 on: March 14, 2019, 08:20:00 pm »
Dave

could you compile to asm  using gcc  5.x.x  http://gus.biysk.ru/os4/test_align.c

1) without -fno-common
2) with  -fno-common

And show results as attachment ?

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #148 on: March 14, 2019, 08:29:49 pm »
I think it is limitations of the aout format. At one point there were plans to switch GCC to outputting ELF and converting that to OMF

AFAIK no need to convert ELF  to OMF    -  wl can link ELF to  LX

I've wondered at that possibility. Still would be a lot more to overcome compared to Win32 such as shared libs vs DLLs.

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #149 on: March 14, 2019, 08:53:53 pm »
Dave, I have been using now for a few days.  Not one crash.  Working great.

David,

It is because you have a good karma  :)   We cannot expect  always  positive result with current  GCC.

I  did the ultimate challenge.  My wife has a facebook page.  She needed me to check something for her.  I logged on and went to her page.  Although the sandybrigde browser did not trap, it slowed down to a crawl making the pages almost unusable.