# Low level programming guidance

This topic is 4156 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Ok so I’ve got my eye on a programming job, but it requires the candidate to have some experience with low level programming. What i was wondering is, where does low level programming fit game programming as a whole? What situations would you apply low level programming and what are the benefits? With this in mind, can anyone recommend a starting point for me? I have done a litte background reading and am guessing i should start by doing some assembly. I would assume that you'd use low level programming in addition to C++ (or whatever language your using) and in that case i could do it using Visual Studio? If anyone could help me out that would be great.

##### Share on other sites
Not that I've ever done these things but I know you can program hardware shaders in assembly language and you can write fast math routines like sqrt, matrix multiplication, etc, in assembler to take advantage of SSE/3DNow type instructions on the CPU.

##### Share on other sites
usually in the modern day the lowest level you would have to program at is with something like the windows api, goes to show how much I know. assembly is the lowest form of programming you would want to go (because binary is just suicide). what I would do is get some older books on assembler. oh btw you can use c++ with assembly, but I think you can only use hooks.

##### Share on other sites
Mastersmith, cheers for the info. What do you mean by hooks?

Ok so maybe having a bit of assembly under my belt might help, even if its not directly related it would be best to understand whats going on if i look at some code. A friend of my who also interviewed there said i should look up bit-shifting, which i've heard about and i understand is kinda low level. But is that in the same vein as assembly?

##### Share on other sites
I don't know what bit shifting is, but since it has the word bit in it I would lean towards it being pretty low level (maybe not assembly low, but still pretty low). what I mean by hooks is like little snippets of assembler in your code or like predefined files that you hook into your program. and it would be good for any programmer to have atleast a basic overview of how everything works at a low level.

but be warned if your going to mess with assembler, back up your hd, because you are working with the memory and cpu at the lowest levels you can really mess up your computer.

hope my info helps you :D.

http://www.freetechbooks.com/forum-27.html
this site provides some stuff for assembler, even for modern day stuff.

##### Share on other sites
Oh ok, cheers for the help mastersmith. If anyone else has anything to add please do so.

##### Share on other sites
Bit-shifting as in:
x = y >> 32;

??

My guess is that when they ask for low-level programming, they're talking about assembly. In a game development context, the only kind of assembly you're ever going to write is usually inline-assembly, so something like (stupid example):

float myFunc() {  float abc = 1.3f;  _asm {    fld [abc]    fsqrt  }}

Much more important than knowing the actual assembly instructions however is knowing about CPU architecture and data representation. That knowledge will also help you with writing more efficient high-level programs.

Things you should know:
- How are integers (signed and unsigned) represented in memory. Hint: twos-complement
- How are floats represented in memory. Hint: IEEE 754, mantissa, exponent...
- How is memory organized in general (code, stack, heap,...)
- How does memory allocation with new/malloc work
- How does alloca work (not saying that you should actually use it)
- How does a function call work. Hint: stack, frames, return addresses,...
- What CPU-registers are there and what are they used for
- How is the FPU organized. Hint: register stack.
- How does the CPU cache work, what's branch prediction
- What are SIMD-instructions, what is memory alignment, SSE-intrinsics
- How does the compiler optimize your code
- How does multi-threading work on the CPU-level

This list is obviously incomplete, but probably a good start.

##### Share on other sites
So, I feel like maybe you've been given some bad advice in this thread. (Hopefully, I'm not about to add to it).

Low-level can either be used in reference to the language (i.e. C# as a high-level language vs. assembly as a low-level language), OR it can be used to refer to what types of systems are being programmed: i.e. device drivers are considered low-level programs (because they're less abstracted away from the hardware than a standard application). Aspects of an operating system (such as the memory allocation routines and various kernel components) are also considered low-level systems.

I believe, when it says a requirement is "low-level programming" it probably means something on the low-level system programming side of things, not necessarily using a low-level language. My theory is that if they wanted you to know an assembly language (there are several), they would have called out which one. Hence my conclusion that they are referring to low-level system programming, not the language being used.

Generally, low-level systems (i.e. drivers, as stated above) require the use of IO interfacing to "talk" directly to the hardware (things like using serial communication, ports, IRQs, communicating to the buses directly, etc), usually there are special low-level routines to be used (such as special kernel-side memory allocation routines, etc). Basically, you're talking straight to the hardware without the usual intermediaries (i.e. an application talks to the display via some sort of interface, like Direct3D or SetDisplayMode, where a display driver would be sending PCI (etc) bus messages directly).

Many drivers are written in C or C++, which are generally considered to be high-level languages (though I would argue that they have some low-level tendencies). I work on display drivers for Windows CE, and our code is pretty much all in C and C++, because CE supports a variety of processor types (x86, ARM, MIPS), and it's infeasible and unnecessary to write special assembly-language drivers for all of our devices.

I may be wrong, they may, in fact, be referring to low-level languages, but I don't believe this is the case.

A good starting point would be learning how something like a system memory allocator works - maybe write your own memory manager, something like that. Read in-depth into how modern kernels work - how they allocate memory, how drivers run, that sort of thing. I'm not really sure. The type of low-level programming required probably depends heavily on what the actual job would be - try to figure out what kinds of lower level systems would be in use with the job described, and do some research.

Good luck, and I hope that helps!

##### Share on other sites
Quote:
 Original post by JimmyDeemoOk so I’ve got my eye on a programming job, but it requires the candidate to have some experience with low level programming.What i was wondering is, where does low level programming fit game programming as a whole? What situations would you apply low level programming and what are the benefits?

Hi,

I am by no means an expert in this sort of thing, but when I was doing my master thesis about computer graphics (not related to games, but I think the example still holds) there was a time when I started to use profilers to discover where most time was spent on the whole thing. I had a basic knowledge of assembly back then, but haven't really used it for years.

Anyway, the most used function I had was something called _ftol / _ftol2 being called about a few million times per frame. After a few googling arround, I discovered that this function was called everytime you made a cast from a floating type to an integer type (and there were a lot of them). Worst, I discovered that this function was also pretty damn slow because it seemed to imply that the CPU had to change it's rounding state, perform the rounding and then restore the CPU's normal state... and this had to be done eveytime you called the function. It seems that the C standard requires that these operations be done everytime you make a C cast.

After a few more diggings, I discovered some assembly alternatives to this, i.e, performing rounding without a call to _ftol. It was a question of a) not doing casts when I actually didn't need them and b) call these assembly alternatives when I had to.

I think that low level stuff such as assembly optimization may be kind of like this... applicable to very specific areas of the code where you know it makes a difference. But that is just my 5 cents... Like I said, I don't know much about it.

Michael Abrash on Pixomatic
It's about the work Michael Abrash has done on the Pixomatic software rasterizer.

##### Share on other sites
Well the job posting is for a games company that product quite big games, for most platforms. So i guess your right in that they are probably looking for someone who knows what implications high-level code has at low-level and also how to improve that to make it more efficient. I read once about something to do with declaring structs, in that there is a way to make sure each members fall into even orderd bytes of memory, thus making it more efficient. I guess these are the kinda of issues i should be looking at.

Drilian, thanks for looking at it from a different angle, i think your thinking is more in the right direction.

Harry Hunt, i believe the first thing you wrote is the bit-shifting i meant. But i'm not sure about what it actually is, or how its used. I guess i've never programmed something thats needed it!?

1. 1
2. 2
3. 3
Rutin
14
4. 4
5. 5

• 9
• 9
• 11
• 11
• 23
• ### Forum Statistics

• Total Topics
633674
• Total Posts
3013275
×