This MIPS simulator will read in a text file consisting of LC3100 machine code instructions (represented as decimal values), and execute the program, then display the values of register files and memory after each instruction is completed.
I do not understand how this can be done and simply need a format for what steps I need to take in order to create the simulator in MIPS. Do I write code in C++ or write the code in MIPS? How do I read files if it is in MIPS? Honestly, just confused.
I do not know where I need to start from. This is what I am asking to help figure out.
I'd imagine you'd want to create some global variables that represent your registers and memory:
int memory[0x80000000/4];
int reg_v0;
int reg_t0;
int* reg_pc;
// etc
And then define some functions that mimic the way MIPS behaves. You'll need to read up on how the CPU operates (which is why this example function may seem arbitrary but really it isn't.)
void MIPS_multu(int regA, int regB)
{
// void because we're writing to global variables.
uint64_t temp = regA * regB;
reg_hi = temp >> 32;
reg_lo = (temp & 0x00000000FFFFFFFF);
}
Finally, you'll need to understand how MIPS instructions are encoded and create a routine that can unpack them and select the correct function.
int memory[0x80000000/4];
int reg_v0;
int reg_t0;
int* reg_pc;
// etc
int main()
{
reg_pc = &memory[0];
while (reg_pc < &memory[0x80000000/4])
// chances are this is either invalid C or just bad practice,
// but I can't think of a better way to express the idea
{
int temp = *reg_pc;
// use bitwise operators etc to figure out what the instruction represents,
// and switch cases to pick the functions.
reg_pc++;
}
}
I am trying to parallelize this for loop inside a function using OpenMP, but when I compile the code I still have an error =(
Error 1 error C3010: 'return' : jump out of OpenMP structured block not allowed.
I am using Visual studio 2010 C++ compiler. Can anyone help me? I appreciate any advice.
int match(char* pattern, int patternSize, char* string, int startFrom, unsigned int &comparisons) {
comparisons = 0;
#pragma omp for
for (int i = 0; i < patternSize; i++){
comparisons++;
if (pattern[i] != string[i + startFrom])
return 0;
}
return 1;
}
As #Hristo has already mentioned, you are not allowed to branch out of a parallel region in OpenMP. Among other reasons, this is not allowed because the compiler cannot know a priori how many iterations each thread should work on when it splits up a for loop like the one that you have written among the different threads.
Furthermore, even if you could branch out of your loop, you should be able to see that comparisons would be computed incorrectly. As is, you have an inherently serial algorithm that breaks at the first different character. How could you split up this work such that throwing more threads at this algorithm possibly makes it faster?
Finally, note that there is very little work being done in this loop anyway. You would be very unlikely to see any benefit from OpenMP even if you could rewrite this algorithm into a parallel algorithm. My suggestion: drop OpenMP from this loop and look to implement it somewhere else (either at a higher level - maybe you call this method on different strings? - or in a section of your code that does more work).
what will be the result of the following C-like program, if the parameter passing mechanism is copy-in-copy-out, like in out in Ada?
During the execution of swap(v, list[v]), v will be updated to 3. When copying out, will the result of the second parameter copied to list[3], or list[1]?
swap(int x, int y){
int t = x;
x = y;
y = t;
}
main(){
v = 1;
int list[5] = {1,3,5,7,9};
swap(v, list[v]);
print v, list[0...4];
}
Ada's parameter passing mechanisim is not copy-in-copy out. Ada is not like C, where the mechanisim is explicit and the compiler will follow it even if it would be stupid to do so.
There are some specific situations where the language specifies that things are passed by reference. Otherwise, it is actually up to the compiler and you are not allowed to rely on one mechanism being used rather than another. In practice, compilers will do the sensible thing, which usually boils down to copy if the object fits in a machine register, and reference otherwise.
What happens in an Ada version of the C code you listed depends on exactly how you translate it to Ada. I suspect what you will find when you do so is that things that would have caused potentially suprising behavior in C, the Ada compiler either won't let you do, or it will force you to document in such a way that it no longer looks wierd.
The parameters are bound before the call is executed, so x is bound to v and y is bound to list[1].
standard C lib:
int fputc(int c , FILE *stream);
And such behaviors occured many times, e.g:
int putc(int c, FILE *stream);
int putchar(int c);
why not use CHAR as it really is?
If use INT is necessary, when should I use INT instead of CHAR?
Most likely (in my opinion, since much of the rationale behind early C is lost in the depths of time), it it was simply to mirror the types used in the fgetc type functions which must be able to return any real character plus the EOF special character. The fgetc function gets the next character converted to an int, and uses a special marker value EOF to indicate the end of the stream.
To do that, they needed the wider int type since a char isn't quite large enough to hold all possible characters plus one more thing.
And, since the developers of C seemed to prefer a rather minimalist approach to code, it makes sense that they would use the same type, to allow for code such as:
filecopy(ifp, ofp)
FILE *ifp;
FILE *ofp;
{
int c;
while ((c = fgetc (ifp)) != EOF)
fputc (c, ofp);
}
No char parameters in K&R C
One reason is that in early versions1 of C there were no char parameters.
Yes, you could declare a parameter as char or float but it was considered int or double. Therefore, it would have, then, been somewhat misleading to document an interface as taking a char argument.
I believe this is still true today for functions declared without prototypes, in order for it to be possible to interoperate with older code.
1. Early, but still widespread. C was a quick success and became the first (and still, mostly, the only) widely successful systems programming language.
Why is it bad practice to declare variables on one line?
e.g.
private String var1, var2, var3
instead of:
private String var1;
private String var2;
private String var3;
In my opinion, the main goal of having each variable on a separate line would be to facilitate the job of Version Control tools.
If several variables are on the same line you risk having conflicts for unrelated modifications by different developers.
In C++ :
int * i, j;
i is of type int *, j is of type int.
The distinction is too easily missed.
Besides having them on one line each makes it easier to add some comments later
I think that there are various reasons, but they all boil down to that the first is just less readable and more prone to failure because a single line is doing more than one thing.
And all that for no real gain, and don't you tell me you find two lines of saved space is a real gain.
It's a similar thing to what happens when you have
if ((foo = some_function()) == 0) {
//do something
}
Of course this example is much worse than yours.
In C/C++, you also have the problem that the * used to indicate a pointer type only applies to the directly following identifier. So a rather common mistake of inexperienced developers is to write
int* var1, var2, var3;
and expecting all three variables to be of type 'int pointer', whereas for the compiler this reads as
int* var1;
int var2;
int var3;
making only var1 a pointer.
With separate lines, you have the opportunity to add a comment on each line describing the use of the variable (if it isn't clear from its name).
Because in some languages, var2 and var3 in your example would not be strings, they would be variants (untyped).
Why is that bad practice? I don't think it is, as long as your code is still readable.
//not much use
int i, j, k;
//better
int counter,
childCounter,
percentComplete;
To be honest I am not against it. I think that its perfectly feasible to group similar variables on the same line e.g.
float fMin, fMax;
however I steer clear when the variables are unrelated e.g.
int iBalance, iColor;
Relevance.
Just because two variables are of type String does not mean they are closely related to each other.
If the two (or more) variables are closely related by function, rather then variable type, then maybe they could be declared together. i.e. only if it makes sense for a reader of your program to see the two variables together should they actually be placed together
Here's my reasons:
Readability, easier to spot if you know there's only one on each line
Version control, less intra-line changes, more single-line additions, changes, or deletions, easier to merge from one branch to another
What about the case such as:
public static final int NORTH = 0,
EAST = 1,
SOUTH = 2,
WEST = 3;
Is that considered bad practice as well? I would consider that okay as it counters some of the points previously made:
they would all definitely be the same type (in my statically typed Java-world)
comments can be added for each
if you have to change the type for one, you probably have to do it for all, and all four can be done in one change
So in an (albeit smelly code) example, is there reasons you wouldn't do that?
Agree with edg, and also because it is more readable and easy for maintenance to have each variable on separate line. You immediately see the type, scope and other modifiers and when you change a modifier it applies only to the variable you want - that avoids errors.
to be more apparent to you when using Version Control tools (covered by Michel)
to be more readable to you when you have the simplest overflow/underflow or compile error and your eyes failed to point out the obvious
to defend the opposite (i.e. multi-variable single-line declaration) has less pros ("code textual vertical visibility" being a singleton)
It is bad practice mostly when you can and want to initialize variables on the deceleration. An example where this might not be so bad is:
string a,b;
if (Foo())
{
a = "Something";
b = "Something else";
}
else
{
a = "Some other thing";
b = "Out of examples";
}
Generally it is, for the version control and commenting reasons discussed by others, and I'd apply that in 95% of all cases. however there are circumstances where it does make sense, for example if I'm coding graphics and I want a couple of variables to represent texture coordinates (always referenced by convention as s and t) then the declaring them as
int s, t; // texture coordinates
IMHO enhances code readability both by shortening the code and by making it explicit that these two variables belong together (of course some would argue for using a single point class variable in this case).
while attempting this question https://www.interviewbit.com/problems/remove-element-from-array/
Method 1 gives Memory Limit exceeded for this code:
Type 1:
int i,j;
Type 2:
int i;
int j;
type 1: Gives Memory Limit Exceeded
int removeElement (int* A, int n1, int B)
{
int k=0, i;
for(i=0;i<n1;i++)
if(A[i]!=B)
{
A[k]=A[i];
k++;
}
return k;
}
Whereas type 2 works perfectly fine
int removeElement (int* A, int n1, int B)
{
int k=0;
int i;
for(i=0;i<n1;i++)
if(A[i]!=B)
{
A[k]=A[i];
k++;
}
return k;
}