72 lines
2.8 KiB
Markdown
72 lines
2.8 KiB
Markdown
# lec14
|
|
|
|
Just like any other binary, those written for MIPS must follow a specific structure for any level of compatibility.
|
|
In the case of MIPS, binaries have a few _sections_ which allow us to cleanly organize our files.
|
|
|
|
_Note that for the rest of this course I'll be discussing the [ELF file format](https://en.wikipedia.org/wiki/Executable_and\_Linkable\_Format), although most of this information is conceptually the same across most other [binary file formats](https://en.wikipedia.org/wiki/Binary_file).
|
|
|
|
## From Disk to Memory
|
|
|
|
### Binaries on disk will have the following structure
|
|
|
|
* Header
|
|
* Think of this like the metadata for the whole file
|
|
* Keep in mind however that every section also has its own respective header that let's the O.S. loader know what is going on.
|
|
* Data section
|
|
* Here you'll find any compile time constants and compile time variables held in this section
|
|
* Text Section
|
|
* This is where the _code_ actually live on disk. Any functions, loops, etc that gets compiled from something like C++ or C will be written to this part of the file.
|
|
|
|
### Binaries in memory
|
|
|
|
|
|
Once the binary is passed through the system loader the operating system will be able to determine that we may need a stack for the newly loaded code.
|
|
I say "may need" because not all binaries require its own stack.
|
|
A shared object file might not need its own stack because it will only be used as kind of _extension_ by some executable binary.
|
|
|
|
At this point any previous structure from disk is preserved as one might expect.
|
|
Once the file is loaded into memory however, the system loader must then also allocate some space of memory for our heap and stack; finally our program is in memory and we can begin execution(right?).
|
|
|
|
## DataTypes
|
|
|
|
Truth be told there are no _types_ in mips or really any assembly language, instead we determine _types_ by their size in bytes.
|
|
In the case of MIPS we have the following types
|
|
|
|
| Type | Size |
|
|
| --- | --- |
|
|
| byte | 1 |
|
|
| half-word | 2 |
|
|
| word | 4 |
|
|
| dword | 8 |
|
|
|
|
Likewise we also have _registers_, which are similar to global
|
|
## Actually writing mips now
|
|
|
|
Just like any other sensible architecture we have the ability in MIPS to use system calls to let us do things like writing to stdout or reading from stdin.
|
|
If you're writing mips code in mars there's a useful list of syscalls [here]().
|
|
|
|
For now let's translate some code to disect the different parts of MIPS.
|
|
|
|
```
|
|
int main(void) {
|
|
write("hello", 5, 1);
|
|
return 0;
|
|
}
|
|
```
|
|
|
|
If you compile this you'll have 1 compile time constant which contains `hello` but in hex followed by 1 byte of `0x00`.
|
|
We also have some code, in this case we want to write something to stdout, then we want to exit the program safely.
|
|
|
|
From the top we have a need for some data:
|
|
|
|
```
|
|
# comments look like this btw
|
|
# first we declare that we have some data
|
|
.data
|
|
|
|
# here is where our 'instructions' lie
|
|
.text
|
|
|
|
|
|
```
|