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

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #105 on: March 08, 2019, 06:32:17 pm »
There's 81 instances of SECTION .text just in libavcodec which I assume aren't getting the use32 FLAT directive.

You may try the following modification:

Code: [Select]
; aout does not support align=
; NOTE: This section is out of sync with x264, in order to
; keep supporting OS/2.
%macro SECTION_RODATA 0-1 16
    %ifidn __OUTPUT_FORMAT__,aout
        SECTION .text
    %elifidn __OUTPUT_FORMAT__,coff
        SECTION .text
    %elifidn __OUTPUT_FORMAT__,obj
        if %1 = 16
            SECTION .rdata align=16  public use32 FLAT class=DATA
        %elif
            SECTION .rdata align=256 public use32 FLAT class=DATA
        %endif
    %elifidn __OUTPUT_FORMAT__,win32
        SECTION .rdata align=%1
    %elif WIN64
        SECTION .rdata align=%1
    %else
        SECTION .rodata align=%1
    %endif
%endmacro

after definition this macro in x86inc.asm  add:

Code: [Select]
%ifidn __OUTPUT_FORMAT__,obj
    SECTION .text align=4 public use32 FLAT class=CODE
%endif

AFAIK  no other changes  are necessary.

To check compilation and linking  add: 
Code: [Select]
global ps_cos16_1
before
Code: [Select]
ps_cos16_1: dd 1.0, M_COS_PI_1_8, M_SQRT1_2, M_COS_PI_3_8, 1.0, M_COS_PI_1_8, M_SQRT1_2, M_COS_PI_3_8
this way we could come to know if ps_cos16_1 is in proper segment with proper alignment

After compilation I would like to see avcode57.map too  :)
« Last Edit: March 08, 2019, 08:07:38 pm by OS4User »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #106 on: March 08, 2019, 10:25:51 pm »
Doesn't like the
Code: [Select]
if %1 = 16 part,
Code: [Select]
src/libavfilter/x86/af_volume.asm:24: error: parser: instruction expected
src//libavutil/x86/x86inc.asm:92: ... from macro `SECTION_RODATA' defined here
make: *** [libavfilter/x86/af_volume.o] Error 1

« Last Edit: March 08, 2019, 10:54:10 pm by Dave Yeo »

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #107 on: March 08, 2019, 10:33:56 pm »
Doesn't like the
Code: [Select]
if %1 = 16 part,

try
Code: [Select]
   if %1 == 16

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #108 on: March 08, 2019, 11:43:59 pm »
Same error.
Anyways there are bigger problems, still using 64kb segments, lots of missing symbols for some reason, perhaps lost when the code is bigger then the segment, inconsistent underline prefix (I just hacked the code to fix for us, changing an ifdef to ifndef). Too many segments.
Here's a map file.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #109 on: March 09, 2019, 12:05:21 am »
Same error.

I am not very good in nasm macro  so for test  you can use  this variant:

Code: [Select]
%macro SECTION_RODATA 0-1 16
        SECTION .rdata align=256 public use32 FLAT class=DATA
%endmacro

hope you give to nasm  -f obj

Anyways there are bigger problems, still using 64kb segments

Did you add

Code: [Select]
%ifidn __OUTPUT_FORMAT__,obj
    SECTION .text align=4 public use32 FLAT class=CODE
%endif

as it was suggested ?

It looks like did not   - that is why you have:

"text                                  AUTO"

and "still using 64kb segments"

---------------

Error! E2028: ff_h264_cabac_tables is an undefined reference  but you have
0001:0010af60  _ff_h264_cabac_tables

it is another story  - may be suggestion from Lars will help https://www.os2world.com/forum/index.php/topic,1735.msg20825.html#msg20825
« Last Edit: March 09, 2019, 12:16:50 am by OS4User »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #110 on: March 09, 2019, 03:29:30 am »
Ok, with the text section added and configure hacked a bit to set the correct prefix (some inline assembler was missing the correct prefix causing the unresolved symbols) compilation finishes.
Still have too many segments though, TEXT32, text and DATA32.
Untested.
Patch for x86inc.asm and avcodec57.map attached

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #111 on: March 09, 2019, 07:41:48 am »
Here's the disassembly of fft.asm in nasm format. If I understand it correctly, the constants are at the bottom of the file in the rodata32 section and aligned to 32 bytes.
It appears the align directive aligns the whole section.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #112 on: March 09, 2019, 07:45:37 am »
Still have too many segments though, TEXT32, text and DATA32.

Wrong segments are:
text                   CODE           AUTO
rodata32               DATA           AUTO

These segments were generated from .asm  (by nasm)  -  I do not know how to tell to nasm that    text  has to be in CGROUP  and  rodata32 has to be in DGROUP

We can try to do this way:

after
Code: [Select]
SECTION .rodata32 align=256 public use32 FLAT class=DATA
add
Code: [Select]
group DGROUP rodata32

after
Code: [Select]
SECTION .text align=4 public use32 FLAT class=CODE
add
Code: [Select]
group CGROUP text

by the way, if we are going to change macro SECTION_RODATA  what  __OUTPUT_FORMAT__  it should  be ready for ?

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #113 on: March 09, 2019, 07:53:29 am »
Here's the disassembly of fft.asm in nasm format. If I understand it correctly, the constants are at the bottom of the file in the rodata32 section and aligned to 32 bytes.
It appears the align directive aligns the whole section.

Better to see in  avcode57.map   at  0004:00000700  ps_cos16_1   - it is pretty good aligned 256 as expected

(I sent you private message - pls see)

Upd:

It  looks  like there is  more straight way  -  select  win32 format for nasm output:  -f win32
No changes  to sources  will be necessary.
« Last Edit: March 09, 2019, 04:01:21 pm by OS4User »

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #114 on: March 09, 2019, 10:59:46 pm »
Same error.
Anyways there are bigger problems, still using 64kb segments, lots of missing symbols for some reason, perhaps lost when the code is bigger then the segment, inconsistent underline prefix (I just hacked the code to fix for us, changing an ifdef to ifndef). Too many segments.
Here's a map file.
You Need to define all segments as public. Only then will they combine.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #115 on: March 10, 2019, 04:28:14 am »
It  looks  like there is  more straight way  -  select  win32 format for nasm output:  -f win32
No changes  to sources  will be necessary.

How to get the symbols to put in the def file? The assembler and compiler object files are mixed together. Currently use emxexp, which pukes on the win32 object files.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #116 on: March 10, 2019, 04:31:44 am »
You Need to define all segments as public. Only then will they combine.

They are declared as public. The weird thing is the various types of text segments. From the map file,
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

Aout gives,
Code: [Select]
TEXT32                 CODE           CGROUP         0001:00000000   00bd1560
________TEXT           CODE           CGROUP         0001:00bd1560   00000000
DATA32                 DATA           DGROUP         0002:00000000   00015a20

Note that the DGROUP ends up in segment 0003.
The other question is, does it matter?

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #117 on: March 10, 2019, 08:01:07 am »
It  looks  like there is  more straight way  -  select  win32 format for nasm output:  -f win32
No changes  to sources  will be necessary.

How to get the symbols to put in the def file? The assembler and compiler object files are mixed together. Currently use emxexp, which pukes on the win32 object files.

What .def ?  Do you need it for some purpose ?

I would like to see avcode57.map  if you give to nasm  -f win32 with this definition of macro:
Code: [Select]
%macro SECTION_RODATA 0-1 16
        SECTION .rodata align=%1
%endmacro

I did not understand if you try suggestion from https://www.os2world.com/forum/index.php/topic,1735.msg20846.html#msg20846  -  pls clarify

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4786
  • Karma: +99/-1
    • View Profile
Re: OS/4 (technical details only)
« Reply #118 on: March 10, 2019, 09:46:09 am »
It  looks  like there is  more straight way  -  select  win32 format for nasm output:  -f win32
No changes  to sources  will be necessary.

How to get the symbols to put in the def file? The assembler and compiler object files are mixed together. Currently use emxexp, which pukes on the win32 object files.

What .def ?  Do you need it for some purpose ?{/quote]
Need a def file to link a DLL
Quote
I would like to see avcode57.map  if you give to nasm  -f win32 with this definition of macro:
Code: [Select]
%macro SECTION_RODATA 0-1 16
        SECTION .rodata align=%1
%endmacro
No map file as the build dies creating the def file
Quote
I did not understand if you try suggestion from https://www.os2world.com/forum/index.php/topic,1735.msg20846.html#msg20846  -  pls clarify

Code: [Select]
YASM    libavcodec/x86/fmtconvert.o
src//libavutil/x86/x86inc.asm:99: warning: segment `text' is already part of a group: first one takes precedence
YASM    libavcodec/x86/flacdsp.o
src//libavutil/x86/x86inc.asm:99: warning: segment `text' is already part of a group: first one takes precedence
src/libavcodec/x86/dirac_dwt.asm:24: warning: segment `rdata32' is already part
of a group: first one takes precedence
src//libavutil/x86/x86inc.asm:91: ... from macro `SECTION_RODATA' defined here

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: OS/4 (technical details only)
« Reply #119 on: March 10, 2019, 10:09:32 am »
You Need to define all segments as public. Only then will they combine.

They are declared as public. The weird thing is the various types of text segments. From the map file,
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

Aout gives,
Code: [Select]
TEXT32                 CODE           CGROUP         0001:00000000   00bd1560
________TEXT           CODE           CGROUP         0001:00bd1560   00000000
DATA32                 DATA           DGROUP         0002:00000000   00015a20

Note that the DGROUP ends up in segment 0003.
The other question is, does it matter?

It does not seem to matter. At least the AVCODE65 that I use has only 2 segments: a CODE segment and a DATA segment.
You can check with THESEUS: System->Modules->AVCODE65->double click one MTE @
The AVCODE65 that I used was installed via RPM from the Netlabs repo.

But you can also enforce that differents segments go into the same group:
CGROUP GROUP ________TEXT,TEXT32,text
put that in an assembler file that is linked, preferably the one for the first obejct file to be linked.
You might get warnings like the one you posted but if it is the FIRST object file to be linked it will take precedence over everything that follows :-)

By the way: I very much doubt that our OS/2 tools can do anything else but the OMF and the AOUT format. I used nasm without the -f switch and that worked right out of the box. Which means that in this case it produces OMF format.
« Last Edit: March 10, 2019, 10:24:35 am by Lars »