mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2006-07-19, 22:48   #1
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2×11×353 Posts
Default Recipe for disaster?

The FFT code has tons of global variables in it. Great for getting quick access to the data, bad for making the FFT code thread-safe.

To make the code thread-safe I want to move all the globals to allocated memory. The assembly code needs a pointer to all this data and I have no free registers.

I came with a possibly dangerous way to do this by changing the stack pointer. I'd allocate a struct
{
char new_stack_space[8192];
char space_for_old_global_data[whatever];
}
On entry to the FFT code, I'd change the stack pointer to use this new allocated stack space. By carefully counting the pushes, pops, and calls, I can access the space_for_old_global_data using the stack pointer.

Does anyone know if this will cause problems on Windows, Windows 64, Linux, or Linux 64?

Should I adopt a slower, safer means of accessing these old global variables?
Prime95 is offline   Reply With Quote
Old 2006-07-20, 00:54   #2
ColdFury
 
ColdFury's Avatar
 
Aug 2002

26·5 Posts
Default

Quote:
Originally Posted by Prime95
The FFT code has tons of global variables in it. Great for getting quick access to the data, bad for making the FFT code thread-safe.

To make the code thread-safe I want to move all the globals to allocated memory. The assembly code needs a pointer to all this data and I have no free registers.

I came with a possibly dangerous way to do this by changing the stack pointer. I'd allocate a struct
{
char new_stack_space[8192];
char space_for_old_global_data[whatever];
}
On entry to the FFT code, I'd change the stack pointer to use this new allocated stack space. By carefully counting the pushes, pops, and calls, I can access the space_for_old_global_data using the stack pointer.

Does anyone know if this will cause problems on Windows, Windows 64, Linux, or Linux 64?

Should I adopt a slower, safer means of accessing these old global variables?
So basically you want to store the "global data" at the bottom of this new stack, and therefore give you a quick way to access it by using esp?

Yes, this should work. In fact, this is how Linux stores per-process data in the kernel level stack.

However:

1) There are ways to get per-thread global data. Glibc and pthreads use this technique, for example, to make errno a per-thread variable. Most techniques I've seen rely on using a segmentation register. This is the best approach, as its well supported, and all of the hard work has been done.

2) How often do you need to switch to this "new stack"? If the switching does not need to happen in a performance critical way, I know a much much safer way to change the stack without having to fiddle with the stack pointer youself. However, it usually involves fiddling with the signal handlers, so its not lightning fast. I don't know if speed is important.
ColdFury is offline   Reply With Quote
Old 2006-07-20, 01:56   #3
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2×11×353 Posts
Default

Quote:
Originally Posted by ColdFury
So basically you want to store the "global data" at the bottom of this new stack, and therefore give you a quick way to access it by using esp?
Precisely.

Quote:
1) There are ways to get per-thread global data. Glibc and pthreads use this technique, for example, to make errno a per-thread variable. Most techniques I've seen rely on using a segmentation register. This is the best approach, as its well supported, and all of the hard work has been done.

2) How often do you need to switch to this "new stack"?
I'll do this stack switch every call to the FFT code. For LL testing that's every 1/100th of a second or so. For ECM and small P-1 runs it will be much more often.

I'll be accessing the global data MUCH more often. While still not absolutely speed critical, faster is better. Portable is a must. Ease of coding (not requiring use of eax, ebx, ecx, edx, esi, edi, ebp) is a requirement.

I'm aware that these OS'es support per-thread global variables but I am concerned about speed and portability.

Your idea of using segment registers is intriguing. Any pointers to how this would work? I'll need to study the ABI (application binary interface) documents and see if they mention segment registers.

If you can, please describe your alternatives as well as the pros and cons of each approach. Thanks.
Prime95 is offline   Reply With Quote
Old 2006-07-20, 12:04   #4
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2·11·353 Posts
Default

Clarification: I've changed the gwnum interface so that gwsetup allocates space for all this global data and returns this pointer to the caller. This pointer is then passed to all future gwnum routines. Thus, I technically do not need thread-local storage. What I need is a clever way to access this allocated data in the assembly code where I do not have a free register available.
Prime95 is offline   Reply With Quote
Old 2006-07-21, 00:32   #5
ColdFury
 
ColdFury's Avatar
 
Aug 2002

26×5 Posts
Default

Quote:
Originally Posted by Prime95
Clarification: I've changed the gwnum interface so that gwsetup allocates space for all this global data and returns this pointer to the caller. This pointer is then passed to all future gwnum routines. Thus, I technically do not need thread-local storage. What I need is a clever way to access this allocated data in the assembly code where I do not have a free register available.
I think your stack approach is the best idea in this case. The segmentation registers are used to access the TLS data segment, but its not very useful if you don't have any free registers anyways.
ColdFury is offline   Reply With Quote
Old 2006-07-21, 01:29   #6
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

2×11×353 Posts
Default

Googling has come up with very little info. One person (http://www.virtualdub.org/blog/pivot/entry.php?id=85) says I can muck with the stack pointer in Windows. One person reported there could be a problem in Wine. I couldn't find any info on changing esp in Linux. I suspect I'll be OK.
Prime95 is offline   Reply With Quote
Old 2006-07-21, 03:50   #7
ColdFury
 
ColdFury's Avatar
 
Aug 2002

26×5 Posts
Default

Quote:
Originally Posted by Prime95
Googling has come up with very little info. One person (http://www.virtualdub.org/blog/pivot/entry.php?id=85) says I can muck with the stack pointer in Windows. One person reported there could be a problem in Wine. I couldn't find any info on changing esp in Linux. I suspect I'll be OK.
Linux doesn't care too much about what you do with esp, just make sure whatever stack you're using has some extra space in it, in case the OS wants to push things onto the stack during a context switch.
ColdFury is offline   Reply With Quote
Old 2006-07-22, 01:56   #8
RMAC9.5
 
RMAC9.5's Avatar
 
Jun 2003

100110012 Posts
Default Probably a Dumb Question but What the Heck ...

I'll ask it any way.

Assuming that you are out of general purpose registers, are there any other registers (mmx, etc.) on the chip that you could safely use?

Also, have you seen my posting in the When the next Prime95 version ? thread?
Is it potentially helpful?
RMAC9.5 is offline   Reply With Quote
Old 2006-07-22, 16:20   #9
dsouza123
 
dsouza123's Avatar
 
Sep 2002

2×331 Posts
Default

George

There are three assembly language forums that have some
very knowledgeble/expert assembly language programmers
using different assemblers both 32 and 64 bit
also with knowledge of using assembly routines linked with c.
A question posted usually has very good results.

Covers many Windows assemblers, NASM32, MASM32, POASM, HLA
Broad assembler knowledge
Post in the Main or Windows API subforums for best results
There is a Linux subforum, some members have Linux experience
http://www.asmcommunity.net/board/

Covers MASM32, GoAsm, POASM, HLA, 64 bit Assembler
Windows with a focus on MASM32, stack/heap/global issues discussed frequently
POASM is Pelle's C/Macro Assembler system (Good MASM32 compatibility)
http://www.masm32.com/board/index.php

Covers FASM under Windows and Linux
http://board.flatassembler.net/

Some of the individual assemblers also have their own separate forum sites.

Last fiddled with by dsouza123 on 2006-07-22 at 16:28
dsouza123 is offline   Reply With Quote
Old 2006-07-23, 03:19   #10
ColdFury
 
ColdFury's Avatar
 
Aug 2002

32010 Posts
Default

Quote:
Originally Posted by RMAC9.5
I'll ask it any way.

Assuming that you are out of general purpose registers, are there any other registers (mmx, etc.) on the chip that you could safely use?

Also, have you seen my posting in the When the next Prime95 version ? thread?
Is it potentially helpful?
He wants to use the registers to address memory, and you can only use a general purpose register for that. Furthermore, I assume he's already using all the SSE registers anyways.
ColdFury is offline   Reply With Quote
Old 2006-07-25, 20:57   #11
Ethan Hansen
 
Ethan Hansen's Avatar
 
Oct 2005

508 Posts
Default

George,

If you are still using Visual C++ for the Win executable, you may need to use the /GS- switch to disable buffer security checking for selected subroutines. I ran into strange behavior when testing a program with unconventional stack usage on Vista. There were no buffer overflows, but the stack pre-allocation routines made hash of the normal execution. No clue if this was a result the beta status of Vista, etc. MS recommended using /GS-. It worked.

Last fiddled with by Ethan Hansen on 2006-07-25 at 20:58
Ethan Hansen is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Windows 8.1 = disaster?? Prime95 Software 15 2013-11-26 14:51
1 TFLOP COMPUTER + Prime95 = Disaster or Superfast crunching? Sutton Shin Software 3 2012-10-19 03:27
Happiness among disaster Historian Puzzles 10 2010-06-22 13:15

All times are UTC. The time now is 07:47.


Wed Jan 19 07:47:55 UTC 2022 up 180 days, 2:16, 0 users, load averages: 1.12, 1.34, 1.60

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔