Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - OS4User

Pages: 1 ... 13 14 [15] 16 17 ... 28
211
But what's more: this mismatch between the filename and the internal module name will eventually massively confuse/screw up the module loader (if done repeatedly) until the whole system reboots without showing any trap screen or the like.

Quote
I could easily create a test case that would blow your whole system just by creating (and loading a DLL) that has a mismatch in filename and internal module name.

What if  you prepare some test so I can run it om my computer and have this reboot?

212
Programming / GCC for ELF
« on: March 24, 2019, 09:30:38 am »
It is impossible  to reach the desirable alignment (32 and 64)  with GCC which produces AOUT object file.  It was  clearly showed  by the recent research and Dave's build  of FFMPEG for AVX.

At same time we hope  if  GCC  _directly_ produces ELF object file it will give us a chance to get alignment 32 and 64.

Actually we need  cc1.exe, as.exe   and a kind of  elfdump.exe to get a list of exports (.def)  for wlink.


213
Applications / Re: OS/4 (technical details only)
« on: March 23, 2019, 09:41:13 pm »
Of interest, a patch was posted for pixman by Intel to use AVX2

OS/4 does not support AVX2

214
Applications / Re: Firefox 45.9 XUL.DLL error
« on: March 17, 2019, 07:05:53 am »
I spoke too soon Dave.  I had a trap, but it did not crash FF.  It just would not play any more youtube video until I closed it and restarted it.  I attached the trap.  It was the XUL.DLL  This was with the OS/2 kernel with the FFPentium.

Now to see if the OS/4 kernel crashes with the FFSandybridge.

Dave,

I see this trap  from time to time on my comp. It is described in  https://github.com/bitwiseworks/mozilla-os2/issues/243

215
Applications / Re: Firefox 45.9 XUL.DLL error
« on: March 15, 2019, 05:32:18 pm »
I'd assume the OS4 kernel has other bug fixes that may prevent those trps. Wish I was more knowledgeable :)

OS/4 has quite a lot of different bug fixes and rewritten parts. It's very difficult to say which bug fixes have prevented those traps.

216
Applications / Re: OS/4 (technical details only)
« on: March 14, 2019, 10:28:21 pm »
Happened to be trying to create an elf object with [H:\tmp\test]gcc_elf --version
3.0.3, which along with regular GCC 3.0.3 gives this output
Code: [Select]
[H:\tmp\test]gcc_elf -c align.c -o align.o
align.c:17:1: warning: no newline at end of file
align.c:8: warning: alignment of `Aligned32_Var1' is greater than maximum object
 file alignment. Using 16.
align.c:10: warning: alignment of `Aligned32_Var2' is greater than maximum object file alignment. Using 16.
align.c:12: warning: alignment of `Aligned32_Var3' is greater than maximum object file alignment. Using 16.

Which I guess is the basic problem.

Dave,

Tnx for .asm files.  One without key  does not look ok
GCC_elf 3.0.3  could be  to old to generate  proper alignment.

David,

We need sites with video but without  JavaScript  to understand the difference.
Pls pay attention to CPUs load.

may be  http://www.quirksmode.org/html5/videos/big_buck_bunny.mp4

217
Applications / Re: OS/4 (technical details only)
« on: March 14, 2019, 09:01:39 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.

Pls do some testing:

1)  reg OS/4 kernel,  P4 FF, latest FFMPEG from Dave
2) nonAVX OS/4 kernel, P4 FF, latest FFMPEG from Dave

And share you opinion about speed  and CPU load on video, especially the sites  where  you got traps.

218
Applications / Re: OS/4 (technical details only)
« 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 ?

219
Applications / Re: OS/4 (technical details only)
« 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

220
Applications / Re: OS/4 (technical details only)
« 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.

221
Applications / Re: OS/4 (technical details only)
« 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.
 

222
Applications / Re: OS/4 (technical details only)
« 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 ?   

223
Applications / Re: OS/4 (technical details only)
« 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.


224
Applications / Re: OS/4 (technical details only)
« 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.

225
Applications / Re: OS/4 (technical details only)
« 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 ?

Pages: 1 ... 13 14 [15] 16 17 ... 28