flat assembler
Message board for the users of flat assembler.

Index > Main > XOR EAX,EAX

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Author
Thread Post new topic Reply to topic
Raedwulf



Joined: 13 Jul 2005
Posts: 375
Location: United Kingdom
Raedwulf
WytRaven wrote:
I understand where Tom is coming from but I don't agree with his solution. Using a low level language to try and write readable code is counter productive. Your comments on this subject till this point tom, have all been arguments that readability in code is infinitely more important than either speed or size in code which begs the question "Why are you interested in assembly at all?". If you want readable code then use a high level language.


pelaillo wrote:
This is a fruitless discussion, but maybe I'm wrong and this time we could put an end to it.
...
The answer is (as everyone is pointing out): writing proper comments and meaningful labels.


Yes, comments are for both deciphering Very Happy and explaining what code does. That is the way for assembly, choose some high-level language if you don't want slightly cryptic code, and remember to leave your C-compiler on /Od (MSVC - Disable all optimisations) or -O0 (GCC), so it generates less cryptic assembly language Smile

For crying out loud!, who doesn't know what xor eax, eax does, who's spent at least a few months programming assembly!!!!!!!!

_________________
Raedwulf
Post 13 Dec 2006, 18:07
View user's profile Send private message MSN Messenger Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
Raedwulf wrote:
For crying out loud!, who doesn't know what xor eax, eax does, who's spent at least a few months programming assembly!!!!!!!!


When you find him, tell us about him so we can have the laughs too... Laughing



edit: no offence meant to anyone, it's perfectly understandable that beginners might not know about it.

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 13 Dec 2006, 18:18
View user's profile Send private message MSN Messenger Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat
Raedwulf wrote:
remember to leave your C-compiler on /Od (MSVC - Disable all optimisations) or -O0 (GCC), so it generates less cryptic assembly language Smile


I've actually found that assembly code from gcc is easier to read with some optimizations. At -O0 it doesn't even do register allocation, so you end up with tons of redundant movs.
Post 13 Dec 2006, 18:53
View user's profile Send private message Reply with quote
smiddy



Joined: 31 Oct 2004
Posts: 559
smiddy
tom tobias wrote:
Zero has always been the most fascinating of all integers. It was only recently invented, (less than two thousand years ago, a microsecond in human evolutionary terms,) well after the discovery of other numbers. So far as I am aware, it is one of many arithmetic discoveries from the Indian subcontinent, though perhaps this is not correct, and it comes in fact from Persia. I am not sure.
Nevertheless, upon "clearing" a register, all silicon is at a state of no measureable voltage, (electrical ground, or neutral), and we define that, arbitrarily, and maybe not correctly, as assigning to the register, the integer value of ZERO.


The Mayas discovered the number zero, and the uses to which it could be put, centuries before it was discovered in Europe or Asia.

Electrical ground and or neutral are not always seen or interpreted as zero, most times in complex systems zero potential is actually refered to as a one, since the likelyhood of a zero is greater than a one. This potential kept at a high dampens the effect of ground bounce and is generally better for multibused circuits.

Saying no measureable voltage too is a relative thing. I've created and used instruments that will measure voltage at the pico potential.

But, that is not your point, and I'm nit-picking for sure here...Wink


tom tobias wrote:
LocoDelAssembly wrote:
..."AND reg, 0" since it clearly demonstrates that you are clearing the register while with "MOV reg, 0" you are assigning 0 to it...
The difference is this: AND is a Boolean operator, which also happens to clear the register, under certain test conditions. MOV is absolute, not relative, like AND. For readability, as well as FOR SIMPLICITY (oh, there's a word the FASM forumers despise!) stick with MOV. For those who prefer OBSCURITY, ok, fine, be obtuse.


Wow, a pun, ambiguous, but none the less a pun, you joker!

I think though if the intention is to squeeze more uses out of your intended goal, the boolean approach might make sense but that has to be
given as the the engineering being done and to what application. Though, I mean to be pragmatic.

tom tobias wrote:
Comments, cher Raedwulf, ought to explain WHAT the code is doing, not HOW to decipher the code into readable text. In other words, the comments ought to explain WHY we are testing the value of the register, (i.e. the value of the flag), not simply informing us of the fact that we are ACTUALLY ONLY testing a Register's value, rather than performing a Boolean operation on the Register, counterintuitively, since both the name and the function of the instruction, suggest the latter. Again, this is a question, first and foremost of whether or not one is writing CODE for one's own interest, one's own project, or one is participating in a GROUP effort. If for oneself, fine, write anything, no problem. But, if one hopes to have a GROUP understand this task, it better be written in the EASIEST POSSIBLE manner. The single most important aspect of attaining success on any GROUP project, is readability.


I don't have an arguement here, I agree. Though your prose have a runeth-over when written, which seems to lump all you thoughts together, leading into...


tom tobias wrote:
For assembly language programming, please do not waste your time, trying to save memory or decrease execution time (especially NOT in a boot loader, Smiddy!!!).


I suppose I have no choice but to respond to this...later.

tom tobias wrote:
Make your PROGRAM as user friendly as possible, by emphasizing the EXTRA instructions, which make it possible for someone other than yourself to understand what you are trying to accomplish. The obsolete 512 byte limit is just that. OBSOLETE. Forget it. Readability is the MOST important feature in today's world, with the international community obliged to use English. Give folks all the help you can, by making your code as simple to understand as possible.


Yes, 512 bytes is a legacy issue but it is still relivent and to some a requirement. Not everyone is on the bleeding edge of technology within (as I assume most are here) their hobby (at least for me this is true). If you impose a requirement that you have to have a FAT 12 compatible boot loader that is to remain within 512 bytes, that is a good and practical requirement. That requirement drives how you write the application to load your application. It is valid!

Is it part of today's technical front end, no. Learning and emulating historical technologies helps to learn where we've been and how we got to where we are currently.

tom tobias wrote:
LocoDelAssembly wrote:
...allows the CPU to get more instructions inside its 16 bytes packets....
Correct me, if I am in error, Smiddy, the memory controller reads in, each clock cycle, 128 bits of data, http://www-128.ibm.com/developerworks/library/pa-tuncpc/
the memory doesn't care if it is sixteen 8 bit ASCII characters, or 128 bits of I/O from the environment. I am unaware of any "packets" here....Decoding the 128 bits, assigning some to data, some to instructions, is certainly complex, BUT I DOUBT that it is more or less efficient to decode a MOV versus XOR. As far as I am aware, both instructions can be decoded from the 128 bit chunk of memory, in the same amount of time.


It really depends on the controller, but you know this already. It also depends on what you're doing too. If you look at the x86's initial archetecture and design the CPU (where BTW all the mov, pop, stc, etcetera happens, regardless of memory), the sensing of address lines and it was one clock cycle per sense, but there are a lot more thing happening today and you can get multiple reads per clock cycle, however it should be transperant to the CPU and essentially you are correct, from a high level.

tom tobias wrote:
Let's suppose I am WRONG. Then what? I don't care. I certainly will not change my thinking about the critical importance of writing PROGRAMS instead of CODE, just because the MOV instruction requires 489 more nanoseconds to decode than XOR.


Well, I won't suppose you are wrong, I will suppose that your opinion is important and requires review.

I also think you do care! Otherwise why write?

I get the gist of this, but I suspect you have to write more to support what you mean as far as CODE or PROGRAMS (APPLICATIONS). But what you've written seems to be an over simplification. Please start a new thread entitiled Code and/or Programs or something similar. I suspect those reading your writing don't fully grasp the meaning you're trying to portrait.

tom tobias wrote:
smiddy wrote:
...be pragmatic in your approach...
Hmm. NOPE, don't agree at all, but then, I dislike the "pragmatic" solution to world environmental, economic, and political problems, too. I believe there is a correct way to do things, and an incorrect way. As far as I am concerned, deliberately misusing an instruction, just because of convention, or laziness, is not proper conduct. Smile


Pragmatism is something that has energy and will continue to survive/thrive. It is that approach to problem solving that continues to improve and make technology what it is today. Nothing is entirely black or white. There is a fair amount of gray to everything.

I don't think your ethememe works, misusing instructions equates to convention therefore is laziness therefore is not proper conduct. Especially since the truth if even further from the analogic arguement you present. But then again, I digress...

My point is it depends on the situation in which you are in to use the tools you have in order to solve problems. You don't write code/programs/applications without having a problem to solve. If your problem is to catch fish to survive, you will devise a way to muster it. The way you're doing it now has to change because now the paradigm has changed, the fish have moved or gotten smart to your way of doing things, so you're forced to solve another problem. Then, it gets to the point where you no longer just survive, you're thriving. Now you get ambitious and you want to thrive even more, so now your problem changes and you come up with further different ways to handle what your goal is. The point is, you have to think about the goal in order to satisfy the goal, and you'd use the tools avialable to satisfy that goal, no matter how. If convention got you there, there is no harm in using that convention...conventions are no the root of all evil. Wink
Post 13 Dec 2006, 20:55
View user's profile Send private message Reply with quote
Plue



Joined: 15 Dec 2005
Posts: 151
Plue
If you want readable programs you don't chose assembly. If you want fast programs you chose assembly. If your main concern is readability, then you're using the wrong language.
If you want the most efficient program without compromising readability create a macro named CLEAR <register> to expand into XOR <register>, <register>.
Post 13 Dec 2006, 21:07
View user's profile Send private message Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
gunblade
Hah! And I thought tom wrote long posts.. that's got to have taken you a while to write smiddy Laughing

I just felt like saying that I agree with the comment that comments should be used to describe what the code is doing. If you are coding in assembly, then odds are you're coding in assembly for a reason: size, speed, low level hardware access. Therefore it is more important for the actual executable created to be as optimized as possible, rather than "readable" (in the executable).

That last line didn't make as much sense as i hoped it would, what I mean is: by using more "readable" opcodes, you are causing the executable to actually contain extra code for nothing, it would be like adding debugging symbols to the binary (which would be fine for debugging, but not for the final output). The binary does not need to be readable, that is why comments, which aren't put into the binary, are better used for readability. That way you get readable code, without the disadvantage of a bigger/slower binary.

Apologies for the bad grammar.

Edit: Just read that post above me by Plue. He actually make a good point, if you want readable, but still using the more efficient versions of the instructions, why not just use a macro? It'll add clarity with no side-effects to the final binary. Nice one Plue! Very Happy
Post 13 Dec 2006, 21:37
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
CLEAR <register> isn't nearly readable enough!
Someone might assume you are making the register transparent or invisible somehow.

SET_ALL_BITS_IN_THIS_REGISTER_TO_ZERO <register> now that's a macro name we can ALL understand.

Very Happy Very Happy Very Happy Very Happy
Post 13 Dec 2006, 22:17
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
tom: just one little thing (again). x86 instruction "and" is NOT same as boolean operation "and"
Post 13 Dec 2006, 22:22
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7751
Location: Kraków, Poland
Tomasz Grysztar
vid wrote:
tom: just one little thing (again). x86 instruction "and" is NOT same as boolean operation "and"

It IS a boolean operation in a sense of general mathematical definition. The Boolean algebra may be built on a set larger than two elements. In fact the boolean algebra of 32-bit words with AND and OR operations is isomorphic to the algebra of the power set of some 32-element set, with the intersection and union operations.
Post 13 Dec 2006, 23:08
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
and how does setting / clearing particular flags fit into your isomorphic boolean algebra with the intersection and union operations blah blah? Wink
Post 13 Dec 2006, 23:23
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7751
Location: Kraków, Poland
Tomasz Grysztar
It's an intersection or union with a singleton.
And I forgot to add that negation transforms by that isomorphism into operation of taking a complementary set... Wink

The idea of this isomorphism is really simple: every subset of a given set of 32 elements can be represented as a function on those 32 elements with values 0 or 1 - 1 if element belongs to this subset, 0 otherwise. Thus 00...00 represents an empty subset, 11...11 represents the whole set, and 10...00 is one of the singletons (only the first element belongs to a subset, thus this subset has just one element).
Post 13 Dec 2006, 23:35
View user's profile Send private message Visit poster's website Reply with quote
MichaelH



Joined: 03 May 2005
Posts: 402
MichaelH
Vid

Quote:

tom: just one little thing (again). x86 instruction "and" is NOT same as boolean operation "and"


From Intel Opcodes and Mnemonics -
Quote:

NOT - One's Compliment Negation (Logical NOT)
Usage: NOT dest
Modifies flags: None
Inverts the bits of the "dest" operand forming the 1s complement.


I was just getting to understand xor, or, and and, and you go add NOT ..... dam it, now I've added add Sad


From Intel Opcodes and Mnemonics -

Quote:

ADD - Arithmetic Addition
Usage: ADD dest,src
Modifies flags: AF CF OF PF SF ZF
Adds "src" to "dest" and replacing the original contents of "dest".
Both operands are binary.


man this assembler thing is confusing Smile
Post 13 Dec 2006, 23:54
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
My "duplicate" post exposed a large need to discuss this issue Very Happy

Instead of all those complicated instructions, Intel possibly should have
implemented something like:

Code:
ZER reg 

Zeroizes a register 

LOK reg

Looks at the value in a register, and sets flags, same effect as CMP reg,0
    


Shocked

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 14 Dec 2006, 00:50
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
tom tobias, I guess you're impressed with languages like COBOL and not so impressed with Brainf*** or Whitespace. Laughing

Tomasz, Confused Shocked Surprised Rolling Eyes Laughing
Post 14 Dec 2006, 03:46
View user's profile Send private message Visit poster's website Reply with quote
Kain



Joined: 26 Oct 2003
Posts: 108
Kain
This program may come in handy if someone is having difficulties understanding how bits and flags are affected in boolean algebra, as well as in various other CPU instructions.
[It can also be used by advanced programmers for working out bit masks]


Description: v1.06
Download
Filename: cCalc.zip
Filesize: 10.38 KB
Downloaded: 312 Time(s)


_________________
:sevag.k
Post 14 Dec 2006, 06:41
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Alas, poor Shoorick (with apologies to Shakespeare's Hamlet from 1603), the algebra preceded the solder, silicon and solid state solutions.
http://www.winasm.net/forum/index.php?showtopic=770
George Boole's 1854 monograph The Laws of Thought appeared nearly a century before invention of the transistor: http://plato.stanford.edu/entries/boolalg-math/
In other words, when Tomasz writes about lattices:
Tomasz wrote:
...It's an intersection or union with a singleton.
he is explaining Boolean LOGIC in Algebraic terminology, a method quite incomprehensible to some of us. Here is another attempt to explain Boolean LOGIC in symbolic terms.
http://www.eelab.usyd.edu.au/digital_tutorial/chapter4/4_1.html
Since Shoorick, Smiddy and I, among many, many others on the FASM forum understand the smell of solder much more readily than lattice algebras: http://en.wikipedia.org/wiki/Lindenbaum%E2%80%93Tarski_algebra
it is generally simpler for us to think about "lattices" and "intersections" and "sets" in terms of NAND gates or their equivalent. We all end up in the same place: Boolean LOGIC. In my opinion, Boolean LOGIC, PRECEDES Boolean algebra. http://mathworld.wolfram.com/BooleanAlgebra.html
This is not obvious, and for some on the forum, will seem irrevlevant to the central question posed by NTOSKRNL_VXE: i.e. why should we employ the "nonsensical" instruction XOR to clear a register? I guess that many skillful mathematicians, including Tomasz surely, could argue against me, that by ALGEBRAIC THINKING, XOR of member 1 with member 1 of a particular set in the lattice corresponds to zero.
Consider this illustration from the same excellent Wikipedia reference kindly furnished by Tomasz:
wikipedia wrote:
... "Give me all the red and blue berries" usually means ... "Give me all berries that are red as well as all berries that are blue". ...
"You want ice cream and candy? You may have ice cream or candy." (logical XOR)
Note that she will receive one or the other, her receiving ZERO sweets represents an invalid, undefined circumstance.
wikipedia wrote:
...
A case where this is an issue is when specifications for a computer program or electronic circuit are supplied as an English paragraph describing their function. For example, the statement "the program [e.g. for voter registration,] should verify that the applicant has checked the male or female box", should be taken as an XOR.
The registration will not be accepted unless one box or the other is checked.

In other words, Boolean logical XOR, as opposed to Boolean Algebraic XOR, does NOT convey THE MEANING of nothingness,
http://en.wikipedia.org/wiki/Being_and_Nothingness
i.e. irrelevance, or zero, on the contrary, it implies that SOMETHING MUST BE CHECKED on the voter registration form, leaving the two choices unmarked represents an invalid condition, i.e. not a legitimate XOR condition, in terms of Boolean logical, as opposed to Boolean algebraic, thinking.
So, in my opinion, the facility of programming with the Intel instruction set to (mis)use an ILLOGICAL instruction, XOR, to create NOTHINGNESS, zero, when the semantic concept implies a REQUIREMENT for SOMETHING to be present, leads to difficulty understanding the program, i.e. supports the concept of creating code. Why should ease of comprehension be important? In terms of solder, this situation (using XOR to clear a register, using OR to test a register) is equivalent to a tangle of wires, all the same color, some connected to earth, some to five volts, some to twelve volts, some to negative five volts, and all of them intertwined without labels or diagram. (FASM!) Does it work, YUP. Can it be readily modified by someone else? NO. Is that tangle deliberate-->CODE.
Smile
Post 14 Dec 2006, 12:28
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo
I was right in one thing: this discussion is fruitless Smile
Quote:

(FASM!) Does it work, YUP. Can it be readily modified by someone else? NO

tom tobias, it seems that you have difficult at reading fasm sources. Please stop blaming the fasm and bashing it every time you can and start doing a sincere effort to learn the language. Maybe you will be able to use it and benefit from it.
Post 14 Dec 2006, 13:56
View user's profile Send private message Yahoo Messenger Reply with quote
WytRaven



Joined: 08 Sep 2004
Posts: 45
Location: Canberra, Australia
WytRaven
Quote:
Does it work, YUP.


to accurately represent the situation this should be "Does it work better, YUP."

Quote:
Can it be readily modified by someone else? NO.


...Does anybody care? NO. Because that's not the point...

tom you are quite obviously an intelligent individual which is why I am baffled that you continue to argue the point of writing readable assembly. Assembly is not meant to be readable it is meant to give you the freedom to do exactly what you want/need with the processor and its supporting hardware. The problem of code readability, portability, and any other 'ability' you can think of has already been solved. The solution was the development of higher level languages that hide the unreadable code at the cost of raw performance and complete control. It seems to me that what you are actually arguing is that we should not be using assembly at all; that we should be using the highest level, most readable language available with little to no consideration for performance. If this is what you really mean then please contact Microsoft and give them a demo of your CODE vs PROGRAMS spiel. I'm pretty sure they will offer you a .NET lobbyist job in a flash.

Unfortunately I am starting to feel that your opinions on this matter are beginning to amount to pollution in the context of this message board and its subject.

_________________
All your opcodes are belong to us
Post 14 Dec 2006, 14:49
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
On this, the one year anniversary of the late Professor Dandamudi's untimely death, permit me to quote from his masterpiece, in response to the suggestion that my quest for readable code represents futility: i.e. fruitlessness, or "pollution" (not pollenation, that would be fruitful Razz ):
Introduction to Assembly Language Programming, (second edition) Sivarama Dandamudi, 2005, Springer Verlag, 690 pages.
Chapter 14: Protected-Mode Interrupt Processing, pg 417:
line 36:
mov ECX, 0
...
line 41:
cmp EAX, 0
*******************
Why didn't Dandamudi use XOR to clear EAX?
Why didn't he use OR, instead of CMP?

Not satisfied?
Here's Richard Dettmer's newest book (he has written many.)
Essentials of 80x86 Assembly Language, R.C.Detmer (2007) Jones and Bartlett, 305 pages.
from page 144, chapter 4:
".CODE
_start;
; find sum and average
mov eax,0 ; sum := 0
mov ecx,0 ; index := 0
..."
Hmm. Why doesn't Dettmer teach his students to use XOR for this purpose?
Oh, that's only TWO university faculty members. Two out of how many thousand? You require more convincing? Or, perhaps you believe that those university folks who teach assembly language programming, probably don't know as much about real programming as the FASM forumers, right? How about Richard Blum, he is not an academic guy, just a bloke like many of us....
Professional Assembly Language, Richard Blum, WROX press, (2005) 546 pages:
page 145, chapter 6:
...
movl $0, %ebx

This is the ATT syntax, but, the point is clear, he is assigning the value of zero to EBX, using the MOV instruction, rather than XOR. He is not using a Boolean operation to accomplish his goal of clearing a register....

These quotes are not limited to recent books on the subject, one finds this same devotion to readability among many older publications. Here are quotes from three of my favorite texts:
80x86 Assembly Language Programming, by D.S. Jones, (1991) Oxford University Press,
Chapter 5, page 102:
cmp CX,0 ; test if CX = 0
....
Advanced Assembly Language, Allen L. Wyatt,Sr. Que publications, (1992) 705 pages;
chapter 10, page 402:
cmp AX, 0 ; Are we done?
page 403:
mov DL,0
....
mov AH,0

It isn't just a few texts and references. It is the VAST majority of publications, at least among the couple dozen references in my collection:

Developing your own 32 bit operating system, by Richard A. Burgess, (1995) Sam's publishing, 741 pages:
page 434, Initialization Code:
MOV ECX, 0
page 443, Job Management Code:
CMP EAX, 0

For me, this is similar to the situation we encounter at international meetings, and conventions. It is difficult to communicate in any language, and still more difficult to use English, but then, someone comes along with an unorthodox method of presenting results, (the FASM FORUM method!!) and the chore of understanding just became much more difficult than necessary. Can you use Boolean operators to perform mundane, non-Boolean tasks? Yes. Should you do that in order to create good, high quality programs? No.
Smile
Post 14 Dec 2006, 19:23
View user's profile Send private message Reply with quote
Plue



Joined: 15 Dec 2005
Posts: 151
Plue
GCC, with -O0 uses mov eax, 0
GCC, with -O2 uses xor eax, eax
Do you think that's simply for fun? No, it's because it's faster!

Now most of us at this forum, do you think we use assembly because we want fast programs or readable programs?

Basically, if you want readable programs more than you want fast programs you shouldn't use assembly unless you don't know better ... and in that case, you should know better now, after I told you. Go and use pascal if you want to write readable programs.

How authors does it in books isn't very relevant. I've got a book on compiler technique, which, at the end uses only two registers and a lot of pushes and pops instead of using multiple registers.
"Writing compilers and interpreters, an applied approach using C++" by Ronald Mak, page 814 wrote:
... for the Pascal assignment statement:
Code:
count := count + 1    
our compiler generates code similar to:
Code:
mov ax, WORD PTR count_083
push ax
mov ax, 1
pop dx
add ax, dx
mov WORD PTR count_083, ax    
Does that mean that GCC should do it like in that book? That would be correct, since that's the way the book does it, right?
Post 14 Dec 2006, 20:37
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next

< Last Thread | Next Thread >
Forum Rules:
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
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.