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

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #120 on: March 10, 2019, 11:01:55 am »
I'll test tomorrow, it's bedtime here.
Wlink claims it can link win32 and OMF object code. Whether it'll work for OS/2 binaries remains to be seen.
Xfree86 actually used ELF code and included an ELF loader to use Linux modules. Needed GCC-ELF etc to build it.
Did NASM produce 32 bit OMF without -f? According to the docs, it will use the native object format but I'd expect 16 bit.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #121 on: March 10, 2019, 11:20:22 am »
Code: [Select]
Segment                Class          Group          Address         Size
=======                =====          =====          =======         ====

TEXT32                 CODE           CGROUP         0001:00000000   009fe590
________TEXT           CODE           CGROUP         0001:009fe590   00000000
text                   CODE           AUTO           0002:00000000   000ca2cb
DATA32                 DATA           DGROUP         0003:00000000   0001d990

try this addition  to  x86inc.asm:
Code: [Select]
; NOTE: This section is out of sync with x264, in order to keep supporting OS/2
%ifidn __OUTPUT_FORMAT__,obj
    %define .text TEXT32
    SECTION .text align=4 public use32 FLAT class=CODE
%endif
it should avoid altering 118 .asm files and remove "text                   CODE           AUTO"
Better to keep this after  definition of SECTION_RODATA macro

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #122 on: March 11, 2019, 01:51:45 am »
try this addition  to  x86inc.asm:
Code: [Select]
; NOTE: This section is out of sync with x264, in order to keep supporting OS/2
%ifidn __OUTPUT_FORMAT__,obj
    %define .text TEXT32
    SECTION .text align=4 public use32 FLAT class=CODE
%endif
it should avoid altering 118 .asm files and remove "text                   CODE           AUTO"
Better to keep this after  definition of SECTION_RODATA macro

Ok, that was what was needed. New zip uploaded to Bitbucket, replacing old upload. Map files in zip. David, please test.
I'll attach the latest diffs. Still have to solve the mangle prefix, perhaps by adding an option to configure.

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #123 on: March 11, 2019, 02:27:36 am »
Dave, I am still getting traps.  This is with the FF sandybridge, OS/4 kernel SVN5452 and your latest libs
« Last Edit: March 11, 2019, 03:02:41 am by David Graser »

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #124 on: March 11, 2019, 07:07:13 am »
Dave, I am still getting traps.  This is with the FF sandybridge, OS/4 kernel SVN5452 and your latest libs

Dave,

It is because of wrong alignment  of   _ff_cos_32:
Code: [Select]
vmovaps ymm0, yword [_ff_cos_32]
fft.asm      Line 182

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #125 on: March 11, 2019, 07:36:10 am »
Only the FIRST variable in the section is aligned to the desired alignment.The others need to be aligned manually.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #126 on: March 11, 2019, 12:18:41 pm »
Only the FIRST variable in the section is aligned to the desired alignment.The others need to be aligned manually.

Lars,

ff_cos_32  defined in C,  what is defined in asm  right now is aligned ok

Dave,

 What version of GCC do you use ?
« Last Edit: March 11, 2019, 01:05:58 pm by OS4User »

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #127 on: March 11, 2019, 03:40:58 pm »
Only the FIRST variable in the section is aligned to the desired alignment.The others need to be aligned manually.

Lars,

ff_cos_32  defined in C,  what is defined in asm  right now is aligned ok

Really ? I could see various variables that were only aligned to 16 bytes (typically it was a sequence of 4 * 4 bytes). If these are only accessed by SSE code then everything is fine but if you pass these to AVX code then you will experience a trap.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #128 on: March 11, 2019, 03:57:47 pm »
Really ? I could see various variables that were only aligned to 16 bytes (typically it was a sequence of 4 * 4 bytes). If these are only accessed by SSE code then everything is fine but if you pass these to AVX code then you will experience a trap.

Interesting to see what do you mean ? (var names)
Vars in asm files are defined  in 3 ways:
SECTION_RODATA        (equ align 16)
SECTION_RODATA 32
SECTION_RODATA 64
so, not all of them have to be aligned 32 or 64.
However,  now  all asm sections are aligned 256.
« Last Edit: March 11, 2019, 08:49:17 pm by OS4User »

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #129 on: March 11, 2019, 10:15:02 pm »
No. The FIRST variable in a section is aligned. But not necessarily the ones that follow.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #130 on: March 11, 2019, 10:35:30 pm »
No. The FIRST variable in a section is aligned. But not necessarily the ones that follow.

True.  But  authors of the code wrote it  with this idea in mind  -  if it was necessary they might have added a direct align 32 directive.

Let us see fft.asm  -  first var  ps_cos16_1 is aligned  because of section alignment, second var ps_cos16_2 also aligned 32  because of the size of ps_cos16_1 is 32 bit  and so on and so on.


Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #131 on: March 11, 2019, 11:12:37 pm »
The whole thing is frustrating. This code has been around and works fine on other platforms, so it has to be problem with our platform, rather nasm or GCC. BTW, I'm currently using GCC 5.5.0 as Paul did some more alignment fixes compared to 4.9.2. I've also switched to building Mozilla for the same reason.
One possibility I guess is that GCC is screwing up with -O3.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #132 on: March 11, 2019, 11:23:46 pm »
One possibility I guess is that GCC is screwing up with -O3.

We'll try a version built with -O2. David could you test the build with -O2 in the zip name? Thanks

David Graser

  • Hero Member
  • *****
  • Posts: 870
  • Karma: +84/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #133 on: March 11, 2019, 11:53:19 pm »
One possibility I guess is that GCC is screwing up with -O3.

We'll try a version built with -O2. David could you test the build with -O2 in the zip name? Thanks
Dave

I tried it and it still traps. 

Right now the ArcaOS kernel does not appear to support AVX, so there is no crash when watching video  The OS/4 standard kernel does support AVX and that is when the problem appears.  The noAVX version of the OS/4 kernel does not crash when playing videos either.

Here are the new trap messages.
« Last Edit: March 12, 2019, 01:59:31 am by David Graser »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #134 on: March 12, 2019, 01:00:33 am »
OK, this is frustrating, especially with my not having AVX hardware. For now just disabling AVX seems the simplest.
Thanks for testing