i'am new at StackOverFlow, i get into trouble and i need your help.
I'am student and i need to write a MIPS program that checks if one string is symmteric.
*sample symmetric strings : ana, asddsa, fillif and so on.
This is my first line of code where i am reading string into an array, but i stucked at the symmetric part.
.data
array: .space 50 # char a[50];
.text
readText:
li $v0,8 # input
la $a0,array # loadiraj memorija vo adresata
li $a1,20 #obezbedi memorija za string
move $t0,$a0 #zachuvaj string vo $t0
syscall
symmetry:
Please give me an opinion, how i should start with symmetry part.
Thanks
Array references are done with pointer arithmetic. First we have to know the location of the variables string1 and i. Let's assume string1 is in $a0 and i is in $t0. We will need to add these two variables together. Whenever we do an arithmetic operation we have to send the result somewhere, and here the idea is to a send the result to a new as-yet-unused register, say $t1. ($a0 and $t0 in this scenario would be a bad place to send the result since those registers hold values we'll need later on in the current or next iteration of the loop.)
add $t1, $a0, $t0
Next dereference that temporary pointer using lbu:
lbu $t2, 0($t1)
again targeting an otherwise unused register.
The C version using three address code would look like this:
char *p;
char ch;
p = string1 + i;
char ch = *p;
Comparison is done with either the beq or bne instruction, both of which take two registers to compare (for equality or inequality, respectively) and a branch target in the form of a label.
We use conditional branches to skip ahead for if-then. The idea is to reason when to skip the then part — and when to skip is the opposite of the if condition as we would write it in C. In assembly: skip this if that, whereas in C: do this if that. Thus, the opposite condition is tested in assembly in order to skip around the then-part.
After learning what .macros were in MARS, I decided to make a few to make my source code more readable.
An example of such a macro is my string length macro:
#Gets the length of a string from an address
#Result is in the second operand
#Doesn't count any null-terminators or newlines at the end of the input
#Call example: strlen MyString,$s0
.macro strlen(%str, %i)
la $t0,%str
__strlen_loop:
lb $t1,0($t0)
#Exit the loop if this byte is null ('\0') or a newline ('\n')
beqz $t1,__strlen_end
beq $t1,'\n',__strlen_end
inc $t0 #Increment-by-one macro
j __strlen_loop
__strlen_end:
la $t1,%str
sub %i,$t0,$t1
.end_macro
This macro works, but it relies on a predefined address in order to work (%str).
To try and remedy this problem, I created the following string length for value strings macro:
#Gets the string length of a value string (stores the string in .data)
#Call example: strlen_v "Hello World!",$s0
.macro strlen_v(%str,%i)
#Create a label for the string
.data
__strlen_v_label: .asciiz %str
.text
#Get the length
strlen __strlen_v_label,%i
.end_macro
Unfortunately, there's another problem. The second macro stores the value string in .data, which only has 0x30000 words' worth of space (address 0x10010000 to address 0x10040000).
It would be preferable to store the value string on the heap instead, since it has much more space and I'll be able to manage the memory more efficiently.
Is storing a compile-time value string on the heap possible without using .data? The only examples I've found were for user-input strings and strings already stored in .data, neither of which apply to this problem.
Is storing a compile-time value string on the heap possible without using .data?
Not really. The heap is conceptually empty on program startup, by definition. And, also by definition, string literals are constants initialized in the data section. You can only allocate heap space at runtime, not at compile time; so, at runtime you can allocate heap space and move strings from literals data into heap...
However, let's note that MARS and QtSPIM allow an argument to .data, which is the location where to place subsequent content. For example, we can do .data 0x10040000, which will cause subsequent string literals to be place there, for example. However, this will interfere with normal heap operation in that your first sbrk syscall will still return 0x10040000, the memory occupied by string literals placed there using .data 0x10040000, as the sbrk syscall isn't aware of the directive.
Defining string length as a function instead of a macro will probably be more of what you want in the long term:
you can determine the length of a string literal, local string, or heap-based string,
your register conventions will fall into the normal calling convention (not sure there even is a register convention for macros),
you will separate the concerns of string literal declaration from string length operation.
Which is more efficient for the compiler and the best practice for checking whether a string is blank?
Checking whether the length of the string == 0
Checking whether the string is empty (strVar == "")
Also, does the answer depend on language?
Yes, it depends on language, since string storage differs between languages.
Pascal-type strings: Length = 0.
C-style strings: [0] == 0.
.NET: .IsNullOrEmpty.
Etc.
In languages that use C-style (null-terminated) strings, comparing to "" will be faster. That's an O(1) operation, while taking the length of a C-style string is O(n).
In languages that store length as part of the string object (C#, Java, ...) checking the length is also O(1). In this case, directly checking the length is faster, because it avoids the overhead of constructing the new empty string.
In languages that use C-style (null-terminated) strings, comparing to "" will be faster
Actually, it may be better to check if the first char in the string is '\0':
char *mystring;
/* do something with the string */
if ((mystring != NULL) && (mystring[0] == '\0')) {
/* the string is empty */
}
In Perl there's a third option, that the string is undefined. This is a bit different from a NULL pointer in C, if only because you don't get a segmentation fault for accessing an undefined string.
In .Net:
string.IsNullOrEmpty( nystr );
strings can be null, so .Length sometimes throws a NullReferenceException
For C strings,
if (s[0] == 0)
will be faster than either
if (strlen(s) == 0)
or
if (strcmp(s, "") == 0)
because you will avoid the overhead of a function call.
String.IsNullOrEmpty() only works on .net 2.0 and above, for .net 1/1.1, I tend to use:
if (inputString == null || inputString == String.Empty)
{
// String is null or empty, do something clever here. Or just expload.
}
I use String.Empty as opposed to "" because "" will create an object, whereas String.Empty wont - I know its something small and trivial, but id still rather not create objects when I dont need them! (Source)
Assuming your question is .NET:
If you want to validate your string against nullity as well use IsNullOrEmpty, if you know already that your string is not null, for example when checking TextBox.Text etc., do not use IsNullOrEmpty, and then comes in your question.
So for my opinion String.Length is less perfomance than string comparison.
I event tested it (I also tested with C#, same result):
Module Module1
Sub Main()
Dim myString = ""
Dim a, b, c, d As Long
Console.WriteLine("Way 1...")
a = Now.Ticks
For index = 0 To 10000000
Dim isEmpty = myString = ""
Next
b = Now.Ticks
Console.WriteLine("Way 2...")
c = Now.Ticks
For index = 0 To 10000000
Dim isEmpty = myString.Length = 0
Next
d = Now.Ticks
Dim way1 = b - a, way2 = d - c
Console.WriteLine("way 1 took {0} ticks", way1)
Console.WriteLine("way 2 took {0} ticks", way2)
Console.WriteLine("way 1 took {0} ticks more than way 2", way1 - way2)
Console.Read()
End Sub
End Module
Result:
Way 1...
Way 2...
way 1 took 624001 ticks
way 2 took 468001 ticks
way 1 took 156000 ticks more than way 2
Which means comparison takes way more than string length check.
After I read this thread, I conducted a little experiment, which yielded two distinct, and interesting, findings.
Consider the following.
strInstallString "1" string
The above is copied from the locals window of the Visual Studio debugger. The same value is used in all three of the following examples.
if ( strInstallString == "" ) === if ( strInstallString == string.Empty )
Following is the code displayed in the disassembly window of the Visual Studio 2013 debugger for these two fundamentally identical cases.
if ( strInstallString == "" )
003126FB mov edx,dword ptr ds:[31B2184h]
00312701 mov ecx,dword ptr [ebp-50h]
00312704 call 59DEC0B0 ; On return, EAX = 0x00000000.
00312709 mov dword ptr [ebp-9Ch],eax
0031270F cmp dword ptr [ebp-9Ch],0
00312716 sete al
00312719 movzx eax,al
0031271C mov dword ptr [ebp-64h],eax
0031271F cmp dword ptr [ebp-64h],0
00312723 jne 00312750
if ( strInstallString == string.Empty )
00452443 mov edx,dword ptr ds:[3282184h]
00452449 mov ecx,dword ptr [ebp-50h]
0045244C call 59DEC0B0 ; On return, EAX = 0x00000000.
00452451 mov dword ptr [ebp-9Ch],eax
00452457 cmp dword ptr [ebp-9Ch],0
0045245E sete al
00452461 movzx eax,al
00452464 mov dword ptr [ebp-64h],eax
00452467 cmp dword ptr [ebp-64h],0
0045246B jne 00452498
if ( strInstallString == string.Empty ) Isn't Significantly Different
if ( strInstallString.Length == 0 )
003E284B mov ecx,dword ptr [ebp-50h]
003E284E cmp dword ptr [ecx],ecx
003E2850 call 5ACBC87E ; On return, EAX = 0x00000001.
003E2855 mov dword ptr [ebp-9Ch],eax
003E285B cmp dword ptr [ebp-9Ch],0
003E2862 setne al
003E2865 movzx eax,al
003E2868 mov dword ptr [ebp-64h],eax
003E286B cmp dword ptr [ebp-64h],0
003E286F jne 003E289C
From the above machine code listings, generated by the NGEN module of the .NET Framework, version 4.5, I draw the following conclusions.
Testing for equality against the empty string literal and the static string.Empty property on the System.string class are, for all practical purposes, identical. The only difference between the two code snippets is the source of the first move instruction, and both are offsets relative to ds, implying that both refer to baked-in constants.
Testing for equality against the empty string, as either a literal or the string.Empty property, sets up a two-argument function call, which indicates inequality by returning zero. I base this conclusion on other tests that I performed a couple of months ago, in which I followed some of my own code across the managed/unmanaged divide and back. In all cases, any call that required two or more arguments put the first argument in register ECX, and and the second in register EDX. I don't recall how subsequent arguments were passed. Nevertheless, the call setup looked more like __fastcall than __stdcall. Likewise, the expected return values always showed up in register EAX, which is almost universal.
Testing the length of the string sets up a one-argument function call, which returns 1 (in register EAX), which happens to be the length of the string being tested.
Given that the immediately visible machine code is almost identical, the only reason that I can imagine that would account for the better performance of the string equality over the sting length reported by Shinny is that the two-argument function that performs the comparison is significantly better optimized than the one-argument function that reads the length off the string instance.
Conclusion
As a matter of principle, I avoid comparing against the empty string as a literal, because the empty string literal can appear ambiguous in source code. To that end, my .NET helper classes have long defined the empty string as a constant. Though I use string.Empty for direct, inline comparisons, the constant earns its keep for defining other constants whose value is the empty string, because a constant cannot be assigned string.Empty as its value.
This exercise settles, once and for all, any concern I might have about the cost, if any, of comparing against either string.Empty or the constant defined by my helper classes.
However, it also raises a puzzling question to replace it; why is comparing against string.Empty more efficient than testing the length of the string? Or is the test used by Shinny invalidated because by the way the loop is implemented? (I find that hard to believe, but, then again, I've been fooled before, as I'm sure you have, too!)
I have long assumed that system.string objects were counted strings, fundamentally similar to the long established Basic String (BSTR) that we have long known from COM.
In Java 1.6, the String class has a new method [isEmpty] 1
There is also the Jakarta commons library, which has the [isBlank] 2 method. Blank is defined as a string that contains only whitespace.
Actually, IMO the best way to determine is the IsNullOrEmpty() method of the string class.
http://msdn.microsoft.com/en-us/library/system.string.isnullorempty.
Update: I assumed .Net, in other languages, this might be different.
In this case, directly checking the length is faster, because it avoids the overhead of constructing the new empty string.
#DerekPark: That's not always true. "" is a string literal so, in Java, it will almost certainly already be interned.
#Nathan
Actually, it may be better to check if the first char in the string is '\0':
I almost mentioned that, but ended up leaving it out, since calling strcmp() with the empty string and directly checking the first character in the string are both O(1). You basically just pay for an extra function call, which is pretty cheap. If you really need the absolute best speed, though, definitely go with a direct first-char-to-0 comparison.
Honestly, I always use strlen() == 0, because I have never written a program where this was actually a measurable performance issue, and I think that's the most readable way to express the check.
Again, without knowing the language, it's impossible to tell.
However, I recommend that you choose the technique that makes the most sense to the maintenance programmer that follows and will have to maintain your work.
I'd recommend writing a function that explicitly does what you want, such as
#define IS_EMPTY(s) ((s)[0]==0)
or comparable. Now there's no doubt at is you're checking.
If strings in a language have an internal length property, checking the length is faster because it is an integer comparison of the property value with zero. However, when strings have no such property, the length must be determined the moment you want to test for it, and this is very fast for a string that actually has length zero, but can take a very long time if the string is huge, which you cannot know in advance, because if you knew it had size zero, why do you need to check that at all?
If a strings don't store their lengths internally, comparing against an empty string is usually faster, as even if that means that the two strings will be compared character by character, this loop terminates after the very first iteration for sure, so the time is linear (O(1)) and does not depend on string length. However, even if strings do have an internal length property, comparing them to an empty string may be as fast as checking that property as in that case most implementations will do just that: They first compare lengths and if not the same, they skip comparing characters entirely as if not even the lengths match, the strings cannot be equal to begin with. Yet if the lengths do match, they usually check for the special case 0 and again skip the character comparison loop.
And if a language does offer an explicit way to check if a string is empty, always use that, since no matter which way is faster, that is the way this check is using internally. E.g. to check for an empty string in a shell script, you could use
[ "$var" = "" ]
which would be string comparison. Or you could use
[ ${#var} -eq 0 ]
which uses string length comparison. Yet the most efficient way is in fact
[ -z "$var" ]
as the -z operation only exists for exactly this purpose.
C is special in that regard, as the string internals are exposed (strings are not encapsulated objects in C) and while C strings don't have a length property and their length must be determined each time needed, it is very easy to check if a C string is empty by just checking if it's first character is NUL, as NUL is always the last character in a C string, so nothing can beat:
char * string = ...;
if (!*string) { /* empty */ }
(note that in C *string is the same as string[0], !x is the same as x == 0, and 0 is the same '\0', so you could have written string[0] == '\0' but for the compiler that's exactly the same as what I've written above)