View previous topic :: View next topic |
Author |
Message |
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Wed Oct 05, 2005 6:26 pm Post subject: CFLAGS for various Athlons? |
|
|
I have a few machines that are running either Athlon MPs or Athlon XPs, and it's getting irritating building separate binaries for each one. I'd like to build one binary for all of those machines - what's the most agressive -march= argument I can use that'll work across both of those? Alternatively, where are those friggin' things documented so I can look this up myself?
Thanks. |
|
Back to top |
|
|
Mattwolf7 n00b
Joined: 14 Mar 2004 Posts: 73
|
Posted: Wed Oct 05, 2005 6:34 pm Post subject: |
|
|
Aren't MPs just XPs that allow dual processor setups?
Post your /proc/cpuinfo
here is mine it is an AMD Athlon XP 2500+
Code: | matt@karma ~ $ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm)
stepping : 0
cpu MHz : 1102.519
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 2170.88
|
by the way it is underclocked right now cause i was having heat issues |
|
Back to top |
|
|
slycordinator Advocate
Joined: 31 Jan 2004 Posts: 3065 Location: Korea
|
Posted: Wed Oct 05, 2005 6:37 pm Post subject: |
|
|
Both are i686 so you could to "mcpu=i686" I believe. |
|
Back to top |
|
|
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Wed Oct 05, 2005 6:56 pm Post subject: Re: CFLAGS for various Athlons? |
|
|
Hooray for Google!
http://gcc.gnu.org/ml/gcc/2002-12/msg00235.html
and
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html
Apparently, both -march=athlon-mp and -march=athlon-xp both imply -mcpu=athlon -m3dnow -msse (where -mtune is the same thing as -mcpu, except that -mcpu is deprecated in gcc 3.4+).
However, I'm still not entirely clear on what to do here. It looks like I can use -mcpu=athlon -m3dnow -msse on both. Great. So I also use -mfpmath=sse. However, the manual says that the code will only be scheduled optimally for the athlon, but there will be no non-386-compatible code generated without a -march switch. So, do I just use -march=athlon, or should I semi-randomly choose between -march=athlon-xp / -march=athlon-mp since they're pretty much the same thing?
It *appears* that merely including -msse and -m3dnow (as well as -mfpmath=sse) in conjunction with -march=athlon should get what I want - maximum processor-specific compile-time tuning for both my Athlon XP and MPs, but I'd be interested in hearing from someone who's not just pulling that out of their butt after 15 minutes of searching and reading. |
|
Back to top |
|
|
nxsty Veteran
Joined: 23 Jun 2004 Posts: 1556 Location: .se
|
Posted: Wed Oct 05, 2005 6:56 pm Post subject: |
|
|
-march=athlon is the best you can use that would work on both. The only thing you would miss on the athlon-xp is sse.
Edit:
-march=athlon includes -mmmx and -m3dnow but not -msse because the athlon-mp doesn't have it.
Edit2:
I was wrong, athlon-mp does have sse so you can use -march=athlon-xp for both (which is the same as -march=athlon-mp) |
|
Back to top |
|
|
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Wed Oct 05, 2005 7:04 pm Post subject: |
|
|
The mp has that extra "mp" cpuflag, while the other machines are actually Semprons (which I was told are supposed to use -march=athlon-xp, and that makes sense as AMD is marketing their "budget" XPs under the Sempron name without actually changing much beyond the CPU ID). So, marketing-wise, I'm not working with any XPs - and they're both actually mp capable. Here's some cpuinfo goodness though, for what it's worth:
Code: | midnight src # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(TM) MP 2400+
stepping : 1
cpu MHz : 2016.854
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 3964.92
processor : 1
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(TM) MP 2400+
stepping : 1
cpu MHz : 2016.854
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips : 4022.27 |
Code: | zipper ~ # cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Sempron(tm) 2800+
stepping : 1
cpu MHz : 1991.240
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mp mmxext 3dnowext 3dnow
bogomips : 3932.16 |
|
|
Back to top |
|
|
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Wed Oct 05, 2005 7:11 pm Post subject: |
|
|
nxsty:
Ok, that agrees with what I found, pretty much. I'll go with Code: | -march=athlon -msse -m3dnow -mfpmath=sse | (among others) and see how that works. That should be identical to -march=athlon-xp, but when I come back to it in a few momths, I'll know what I did this way. If I use athlon-xp on the mp machines, I'm apt to wonder what I was thinking (and yes, comments in the file to remind myself, those are out of the question!). |
|
Back to top |
|
|
yngwin Retired Dev
Joined: 19 Dec 2002 Posts: 4572 Location: Suzhou, China
|
Posted: Wed Oct 05, 2005 7:44 pm Post subject: |
|
|
You could use -march=athlon -mtune=athlon-xp -msse
Don't use -mfpmath=sse that's actually slower on the Athlon-XP (and I guess the MP and Sempron as well), just don't set that flag at all. Other flags that could be helpful are -falign-jumps=16 -falign-loops=16 -falign-functions=64 -mno-push-args -maccumulate-outgoing-args _________________ "Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF |
|
Back to top |
|
|
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Wed Oct 05, 2005 8:25 pm Post subject: |
|
|
yngwin wrote: | You could use -march=athlon -mtune=athlon-xp -msse
Don't use -mfpmath=sse that's actually slower on the Athlon-XP (and I guess the MP and Sempron as well), just don't set that flag at all. Other flags that could be helpful are -falign-jumps=16 -falign-loops=16 -falign-functions=64 -mno-push-args -maccumulate-outgoing-args |
I normally build with -Os, which disables the alignment optimizations.
maccumulate-outgoing-args implies mno-push-args, and generates larger code size. While both the alignment options and the argument handling options almost always result in slightly faster code, they also increase memory usage which makes it more likely that I'll run beyond the physical memory limit and start swapping. I tend to not go for optimizations that will run me out of memory in exchange for an imperceptible speed increase...
Thanks for pointing out the -mfpmath=sse thing, though. Do you have any benchmarks or documentation to back that up? I believe you, but was unable to find anything to either agree or disagree (I'm curious as to why it's slower). |
|
Back to top |
|
|
yngwin Retired Dev
Joined: 19 Dec 2002 Posts: 4572 Location: Suzhou, China
|
Posted: Thu Oct 06, 2005 6:59 pm Post subject: |
|
|
I don't understand why you're so concerned about space and memory, unless you use an old box with very limited harddisk space and limited ram. I use -O2 -finline-functions (the only extra one in -O3 that's worth using on x86, as I understand it).
I don't have any documentation ready, but I do read up on what knowledgeable users, both on this forum and elsewhere, say and recommend, and I follow up on their links, as well as the GCC doumentation. I don't claim to be an expert, but following the advice of experts and reading on the subject whenever I come across it, has led me to use these flags, with good result. I have a stable and speedy system that I am content with. _________________ "Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF |
|
Back to top |
|
|
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Sun Oct 09, 2005 3:46 am Post subject: |
|
|
yngwin wrote: | I don't understand why you're so concerned about space and memory, unless you use an old box with very limited harddisk space and limited ram. I use -O2 -finline-functions (the only extra one in -O3 that's worth using on x86, as I understand it).
I don't have any documentation ready, but I do read up on what knowledgeable users, both on this forum and elsewhere, say and recommend, and I follow up on their links, as well as the GCC doumentation. I don't claim to be an expert, but following the advice of experts and reading on the subject whenever I come across it, has led me to use these flags, with good result. I have a stable and speedy system that I am content with. |
The size of the executable isn't due to a concern with drive space (the difference is negligable at that level) or really with RAM. I use -Os on my modern SMP systems rather than -O2, because the only difference is that -Os doesn't use the alignment optimizations. Those aligmnet optimizations do things like inserting extra space before function calls, loop jump targets, etc. While that can result in a very small performance increase (basically due to simplified mathematical operations), it also spreads code out. That spreading out of code increases the chance of cache misses. On a uniprocessor system with a modern processer that has lots of on-chip cache, that's not a huge deal. However, on an SMP system with separate chips - and thus separate on-chip caches - the performance hits of cache misses can be pretty sigificant - significant enough to outweigh the minor alignment benefit. Having to fetch stuff from system memory is *way* slower than fetching from processor cache - it's like the difference between swapping and fitting in to physical memory. It's this space concern that's the main reason why it's a bad idea to buld everything with -O3 (well, that and -funroll-loops results in slower code when the number of iterations isn't know in advance, which is the case in lots of loops that I write - and presumably in other coders' stuff).
I guess I'm technically worrying about memory, after all, but I'm really worrying about L1 and L2 cache usage, rather than system memory. And there's not much you can do to increase the size of the on-chip cache, which is typically on the order of 128-512K. My pretty current Athlon MP system, for example, has 1.5GB RAM, but the chips only have 256K of cache. When you're tyring to fit as much code as possible into 256K, it's worthwhile to worry about space. Not to mention that compilation time is slightly improved over -O2, and significantly improved over -O3. Referring to is as optimizing for size is deceptive, though, since people do usually think of system memory and drive space first - forgetting about the cache which is arguably more important.
That said, I was able to find more information on the SSE thing which agreed - basically the SSE implementation on the Athlons isn't all that awesome - it's more for compatability. The Athlons do, however, have a kick-ass 387 unit (which is what's used in place of SSE). |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Sun Oct 09, 2005 1:34 pm Post subject: |
|
|
Quote: | Referring to is as optimizing for size is deceptive, though, since people do usually think of system memory and drive space first - forgetting about the cache which is arguably more important.
|
refering to it as size optimisation is perfectly accurate. Any erroneous assumptions anyone may make about how and where that is relevant is only self-deception. Hwvr. thanks for emphasising the effect of the code size in relation to the cache, obviously important.
Quote: |
That said, I was able to find more information on the SSE thing which agreed - basically the SSE implementation on the Athlons isn't all that awesome - it's more for compatability. The Athlons do, however, have a kick-ass 387 unit (which is what's used in place of SSE). |
That's why its best to let the compiler decide rather than forcing the issue with -mfpmath .
See also:
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Optimize-Options.html
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
Obviously add -pipe to just about any system to speed up the compile time by using pipes.
There is info on AMD's site about processor diffs but I cant find the link. As I recall Semperons have SSE2 that athlon-xp does not. Maybe relevant to what you are trying to achieve.
I also find this useful to get around 2G file limits on ftp progs, although it does create an issue with mod_perl I have seen no other probs.
-D_FILE_OFFSET_BITS=64
Thanks for your resumé, I'd never looked thoroughly into -Os, I did not realise it was so close to the -O2 that I generally use. I may do some tests.
_________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Sun Oct 09, 2005 1:39 pm Post subject: |
|
|
@Mattwolf7:
suggest you search for my comments in the gentoo overclocking thread, you're probably running that thing at about half what it is capable!
I find I can knock about 10 C off typical athlon-xp temps just by lapping in the heatsink, and you are a long way from typical.
Sound like you have lousy thermal contact.
HTH _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
yngwin Retired Dev
Joined: 19 Dec 2002 Posts: 4572 Location: Suzhou, China
|
Posted: Sun Oct 09, 2005 3:19 pm Post subject: |
|
|
OK, now I understand your reasoning. But as I understood it, those alignment optimizations are fine-tuned for the Athlon XP (don't know about other procesors) to make optimum use of its cache, and are actually promoted by AMD themselves. (If you search or dig through the Cflags Central thread you might find the link.) _________________ "Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF |
|
Back to top |
|
|
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Sun Oct 09, 2005 3:44 pm Post subject: |
|
|
yngwin wrote: | OK, now I understand your reasoning. But as I understood it, those alignment optimizations are fine-tuned for the Athlon XP (don't know about other procesors) to make optimum use of its cache, and are actually promoted by AMD themselves. (If you search or dig through the Cflags Central thread you might find the link.) |
"Optimum" in this case probably refers to execution speed, not space. The alignment optimizations use padding, and padding wastes space, period. My concern, like I said, is more directed to my SMP systems than the uniprocessor systems. In an SMP system, if the processor looks for code that's not in its cache, in addition to having to fetch the information from the next level up of memory, it *also* has to wait for the other processor to finish whatever it's doing / free up locks, etc. If there are lots of cache misses, then the other processor could *also* be fetching from memory. So, the cache miss is now a little more than twice as expensive than it would be on a uniprocessor system. It's sort of like moving a uniprocesor system to system RAM that's only half as fast. That can pretty quickly negate any gain you get from slightly easier math operations when calculating jump targets.
Of course, that's just a pessimistic generalization - it's plausible that using -O2 won't cause noticable performance differences, and likely that a difference either way won't be felt under typical use. Since I'm generalizing tuning for both SMP and uniproc systems, the odds are in favor of -Os being better for me than -O2. Were I using just uniproc systems (or mostly uni systems), I'd more than likely use -O2, though. |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Sun Oct 09, 2005 5:00 pm Post subject: |
|
|
Optimum in any domain is always relative to what you are trying to do and once you are down scratching around the sub 1% performance gain you really need to define exactly what use you are targetting your system for.
dannysauer: your reasoning sounds good, how about running a couple of tests? Could be interesting.
_________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
Mattwolf7 n00b
Joined: 14 Mar 2004 Posts: 73
|
Posted: Tue Oct 11, 2005 3:14 am Post subject: |
|
|
Thanks Gentree, i underclocked it cause i was having hard locks on it. But I figured out that my graphics card isn't in very tight and the card keeps slipping out and causing the lock.
I was runing my 2500+ at 3200+ by clocking the memory up from 333mhz to 400mhz, so i thought it was something with that so i just kicked it down to 200mhz. I'm just too lazy to reboot and kick it back up
(plus i've had it like this for 2 weeks and haven't really missed the speed all that much, but next reboot i'll fix it [damn linux never needing reboots... ]) |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Tue Oct 11, 2005 7:04 pm Post subject: |
|
|
My benchmark for this sort of thing is emerge gftp, (cos it's small).
I was quite amazed at how much difference these options make to the binaries.
Here's with Os then O2:
Code: | bash-3.00#ls -ail /usr/bin/gftp*
1722399 -rwxr-xr-x 1 root root 333 Oct 11 20:40 /usr/bin/gftp
1722397 -rwxr-xr-x 1 root root 243472 Oct 11 20:40 /usr/bin/gftp-gtk
1722388 -rwxr-xr-x 1 root root 149316 Oct 11 20:40 /usr/bin/gftp-text
bash-3.00#ls -ail /usr/bin/gftp*
1722385 -rwxr-xr-x 1 root root 333 Oct 11 20:45 /usr/bin/gftp
1722381 -rwxr-xr-x 1 root root 309040 Oct 11 20:45 /usr/bin/gftp-gtk
1722372 -rwxr-xr-x 1 root root 186180 Oct 11 20:45 /usr/bin/gftp-text
|
the Os compile took almost 52s against 50.1 with Os. ie -2%; small but nice.
Thanks for getting me interested in this , if files typically coming out 20% smaller I'll probably rebuild this machine on -Os
I'm just doing xorg to see if I can see an speed up as well.
_________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
mr666white n00b
Joined: 24 Aug 2004 Posts: 52
|
Posted: Wed Oct 12, 2005 12:24 pm Post subject: |
|
|
Does anyone know where the Socket 754 Semprons fit into the scheme of things, They show up as as an unknown Hammer processor in /proc/cpuinfo, and I am led to believe they are essentially an athalon 64 with less cache and the 64 bit extentions disabled. I can't post my cpuinfo at the moment as the machiene is currently out on loan, but I can get it if this would help.
Currently I'm treating it as an Athalon XP. _________________ www.technomancer.me.uk |
|
Back to top |
|
|
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Wed Oct 12, 2005 12:45 pm Post subject: |
|
|
mr666white wrote: | Does anyone know where the Socket 754 Semprons fit into the scheme of things, They show up as as an unknown Hammer processor in /proc/cpuinfo, and I am led to believe they are essentially an athalon 64 with less cache and the 64 bit extentions disabled. I can't post my cpuinfo at the moment as the machiene is currently out on loan, but I can get it if this would help.
Currently I'm treating it as an Athalon XP. |
It's a K8/Athlon64 with a smaller cache and 64-bit addressing disabled. I'd treat it like an Athlon XP with sse2 (so add -msse2) from the compiler's point of view, though. |
|
Back to top |
|
|
dannysauer n00b
Joined: 23 Sep 2004 Posts: 60 Location: Lincoln, IL
|
Posted: Wed Oct 12, 2005 12:47 pm Post subject: |
|
|
Gentree wrote: | My benchmark for this sort of thing is |
Cool - I'm glad you've got a it more time for this than I do presently. The amusing thing is that a big part of my job is benchmarking/tuning new hardware, but I haven't had time to run tests on my own machines. |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Wed Oct 12, 2005 1:09 pm Post subject: |
|
|
Quote: | and I am led to believe they are essentially an athalon 64 with less cache and the 64 bit extentions disabled. |
http://www.xbitlabs.com/articles/cpu/display/sempron-2600_2.html
That is, the new Sempron 2600+, 2800+ and 3000+ for Socket 754 are manufactured with 90nm tech process, but are based on the stepping D0 core, so they dont yet support the SSE3 instruction set.
That is, some of the new Sempron models have a smaller L2 cache (128KB, to be exact) than the Sempron 3100+ has (i.e. 256KB).
Or you could always try looking on AMD's site:
http://www.amd.com/us-en/Processors/ProductInformation/0,,30_118_11599_11604,00.html
*SSE2 support is available only with the 754-pin package
_________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
mr666white n00b
Joined: 24 Aug 2004 Posts: 52
|
Posted: Wed Oct 12, 2005 1:20 pm Post subject: |
|
|
My sempron is one of the first 3100+, so i think it based on the old 130nm core. I guess athalon-xp is the way to go for my cflags. As a slight aside, what would happen if I configured the kernel for a k8/hammer rather than an athalon(-xp)/k7? _________________ www.technomancer.me.uk |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Wed Oct 12, 2005 2:01 pm Post subject: |
|
|
http://www.ocinside.de/index_e.html
very handy site for getting the low-down on you extact CPU model, you'll need to pull it out and look at the serial number.
If you want to try -march and -mtune for athlon 64 best check /proc/cpuinfo for sse? in flags and explicitly add or disable in cflags. This seems to be the main compatability diff on these families , obviously the cache size etc. is irrelevant in this context.
As for the kernel I think it is probably safe to try and you will either a get a kernel that will boot or no. Since it is basically a hamstrung Hammer core it should be safe but dont say I advised you to do it _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
playfool l33t
Joined: 01 Jun 2004 Posts: 688 Location: Ã
rhus, Denmark
|
Posted: Thu Oct 13, 2005 3:05 am Post subject: |
|
|
I know several people build Athlon-MP setups using Athlon-XP and some clever hardware hacking, to the best of my knowledge the chips are very similar and since not many MP chips are required and they are built by the same specs - I assume that the odds that a given set of XPs would work as MPs with the correct gates connected are quite high. (I'm not encouraging this it will void warrenty and can make your system go boom - if you break it you get to keep both pieces)
Anyways, I guess this means you can rely on the fact that both cpus have basically the same charactaristics, so the performance drop by using -march=i686 -mtune=athlon-xp would be minimal
There's the basic guide - remember to research the specifics for your athlon core type and don't complain if things become unstable - the cores are probably untested before shipping at the new setting or could be marked down for failing the specific mp test.
http://www.cpuheat.wz.cz/html/AXP_multiplier/AXP_Multiplier.htm |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|