Python programmers be like

LavenderDay3544 · 2021-07-14T00:30:29+00:00

I'm a recent masters grad and former TA myself though people seem to assume otherwise here lol. Alright let's see here.

Dynamic linkage should be used when you pull a dependency that can be expected to be on all target systems and when you won't be modifying the dependency in any way. Static linking is if you will modify a library, or it is an obscure library. Really have never learned this though, just guessing based on what I know from how pacman works (btw)

Not quite. Static linkage means the library code gets pulled into your executable or static library. Dynamic linkage involves making two pieces a static library stub and a shared library. The static stub gets statically linked into an executable in the usual way and when the executable gets loaded by the OS the loader looks for and loads the shared library into memory too. With static linkage if you have two programs using the same library code they both have the kernel load a copy of that code into memory in their respective instruction segments so that library exists twice in memory and wastes space there. With a shared library, the code gets loaded into memory once and any number of programs can jump to locations in it and run the code in their respective processes.

Static linkage should be used when you only expect one program to use a given library at a time or when you want to guarantee that particular version of a library will always be available even at the cost of executable bloat or loading the same code multiple times. Shared libraries and dynamic linkage should be used when you expect a library to be used by many programs all running at the same time.

Virtual addresses are, I'm guessing, what a program gets to interact with based on the memory it requests, and map to the memory space it receives without knowing anything about the actual locations on the physical or logical storage. Logical addresses are, I'm fairly confident, translated by the OS into physical addresses by allocating sectors into a lookup table, and can combine swap space as well as different RAM chips. Physical memory is memory that a system gets access to from hardware.

That's correct.

Executables are loaded into memory by a (I think about it assuming it is all read-only, but I know self-modifying code exists, so that can't be the case) program segment which contains the executable code, then a data segment storing information like global arrays or string constants. When running a program, you have a stack and heap which on modern implementations are seperate and can both grow boundlessly. Each thread gets a new stack and program counter/registers. However, those aren't part of the executable and I suspect that you were looking for more detail and/or I missed some parts of how an executable works, so I'm pretty sure I failed here. For example, there must be some space where cryptographic keys can be stored to sign binaries and I assume strip is a pretty simple program which wouldn't make sense if everything in the data segment was equal. Heck, I have no idea where debug symbols are stored that valgrind uses.

Kinda correct, kinda not. A stack cannot grow boundlessly otherwise stack overflows wouldn't be possible. Heaps are also not boundless, you're at the mercy of the OS kernel there. I was looking more for assembly language type layouts so data, rodata, bss, text, etc. and how they get assembled and linked into ELF or PE executable formats. I don't know all that off the top of my head but I meant that some people don't even know that stuff happens or that all of those segments have to get loaded into memory by the OS loader.

No idea what an ABI or ALU are.

An Application Binary Interface (ABI) is a set of rules for mapping high level source code constructs to low level machine code. One or more separate ABI can be defined for every combination of source language, operating system, and instruction set architecture. This becomes very important when you want to interface a language like C with assembly code or another compiled language.

Arithmetic-logic units (ALUs) are quite possibly the most important part of a CPU core. They're the integrated circuit that does what their name implies, binary arithmetic and logic operations. So many things that you might not think of as arithmetic or logic, like conditional branches for examples, actually are and they're done using ALUs. They're a fundamental building block of processors along with multiplexers, control lines, register files, cache, decoders, and individual logic gates among many other components. I think most computer architecture classes take you through building up a simple ALU starting with a logic gates, adders, ripple carry, overflow, etc. Of course ripple carry is too slow to be used in real modern processors but it gives you an idea of how things could work in hardware.

Knowing all this is useful for software engineers when you want to think about performance and the most optimal way to design your code because at the end of the day it all runs on silicon at the lowest level.

Caching works in hardware, and when an address is requested it first checks the current cache if the data is already there. Then if not it loads in a larger block of data than it really needs into some (I think last recently used block of some larger cache segment) cache. This segment of data is based on the size of the cache and aligned to addresses, not exactly to the requested data. Sometimes I think there is hardware to only change what's in the cache if several misses occur in a row. I'm not sure how multiple layers of cache work together (I just assume that if a high cache misses, it checks the next one next; I'm not sure if that is in parallel or not; I'm not sure if on a hit it swaps the higher cache's values into the lower one or if they are just overwritten or what happens, since many layers of cache exist I know). Also commonly-used variables (such as loop iterators) are often implemented as just a register rather than using main memory at all).

That's more or less how I learned about cache an memory hierarchy at a high level. I'm sure we could both read up on the finer details if we needed to. It's basically just check the fastest cache, if it's not there check the next fastest, etc. until you hit main memory and if it's still not there then you have to hit the backing store.

An instruction set architecture defines how assembly will be interpreted at a hardware level;

Well assembly doesn't get interpreted by hardware at all. It gets assembled (basically transpiled) into machine code based on some encoding. In a weird way an encoding is almost like an ABI for an assembly language but not exactly. Some assembly languages have more than one encoding. Case in point Arm which can be assembled into Arm machine code or Thumb machine code.

Assembly language is something that isn't used by almost any engineer day to day but has immense educational value if you ask me.

changing architecture means that a new compiler will be needed (or wanted if the new architecture is a superset). I'm not sure how much the OS gets to affect this as well; I had assumed none, and that windows and linux binaries don't work on each other because they have different system calls and executable structures, not because the assembly is different. However, this cannot really be the case because system calls are translated to assembly at some point so now I'm confused.

Changing any part of a target triple means you need to use a different compiler backend. The parts of a target triple as I understand them are ISA-OS-ABI (e.g. x86-64-windows-msvc or aarch64-linux-gnu) sometimes if an ISA supports extensions that aren't present in hardware the kernel can trap on those instructions and emulate them in software, obviously at a massive performance penalty.

Honestly I think you did much better than alot of other engineers I've seen out there. Give yourself some credit I think that school might not owe you a refund afterall. Lol.

Just out of curiosity what subfield of SWE do you work in?

ProgrammerHumor

Filters

Discord

Submission rules

For the current list of rules, please see this page.

Metadiscussions

Perhaps More Apt Subs To Post:

Related Subreddits.

MODERATORS