OpenMP Scheduling

• SCHEDULE: Describes how iterations of the loop are divided among the threads in the team. The default schedule is implementation dependent.

  STATIC

  Loop iterations are divided into pieces of size chunk and then statically assigned to threads. If chunk is not specified, the iterations are evenly (if possible) divided contiguously among the threads.

  DYNAMIC

  Loop iterations are divided into pieces of size chunk, and dynamically scheduled among the threads; when a thread finishes one chunk, it is dynamically assigned another. The default chunk size is 1.

  GUIDED

  For a chunk size of 1, the size of each chunk is proportional to the number of unassigned iterations divided by the number of threads, decreasing to 1. For a chunk size with value k (greater than 1), the size of each chunk is determined in the same way with the restriction that the chunks do not contain fewer than k iterations (except for the last chunk to be assigned, which may have fewer than k iterations). The default chunk size is 1.

  RUNTIME

  The scheduling decision is deferred until runtime by the environment variable OMP_SCHEDULE. It is illegal to specify a chunk size for this clause.

  AUTO

  The scheduling decision is delegated to the compiler and/or runtime system.

• NO WAIT / nowait: If specified, then threads do not synchronize at the end of the parallel loop.

• ORDERED: Specifies that the iterations of the loop must be executed as they would be in a serial program.

• COLLAPSE: Specifies how many loops in a nested loop should be collapsed into one large iteration space and divided according to the schedule clause. The sequential execution of the iterations in all associated loops determines the order of the iterations in the collapsed iteration space.

https://computing.llnl.gov/tutorials/openMP/

GNU Make

5.7 Recursive Use of make

Recursive use of make means using make as a command in a makefile. This technique is useful when you want separate makefiles for various subsystems that compose a larger system. For example, suppose you have a subdirectory subdir which has its own makefile, and you would like the containing directory's makefile to run make on the subdirectory. You can do it by writing this:

     subsystem:
            cd subdir && $(MAKE)

or, equivalently, this (see Summary of Options):

     subsystem:
            $(MAKE) -C subdir

You can write recursive make commands just by copying this example, but there are many things to know about how they work and why, and about how the sub-make relates to the top-level make. You may also find it useful to declare targets that invoke recursive make commands as `.PHONY' (for more discussion on when this is useful, see Phony Targets).

For your convenience, when GNU make starts (after it has processed any -C options) it sets the variable CURDIR to the pathname of the current working directory. This value is never touched by make again: in particular note that if you include files from other directories the value of CURDIR does not change. The value has the same precedence it would have if it were set in the makefile (by default, an environment variable CURDIR will not override this value). Note that setting this variable has no impact on the operation of make (it does not cause make to change its working directory, for example).

• MAKE Variable: The special effects of using `$(MAKE)'.
• Variables/Recursion: How to communicate variables to a sub-make.
• Options/Recursion: How to communicate options to a sub-make.
• -w Option: How the `-w' or `--print-directory' option helps debug use of recursive make commands.

PC Systems Programming Essentials

[source: http://atrevida.comprenica.com/gameprog.html]

• Introduction to Binary and Hexadecimal (~27K)
• Binary Operations (~26K)
• Binary Manipulations (~10K)
• Memory in the PC (~23K)
• Calling Interrupts (~21K)
• Hardware Ports (~20K)

C Programming Notes

[source: http://www.eskimo.com/~scs/cclass/notes/]

Introductory C Programming Class Notes, Chapter 1

Steve Summit

These notes are part of the UW Experimental College course on Introductory C Programming. They are based on notes prepared (beginning in Spring, 1995) to supplement the book The C Programming Language, by Brian Kernighan and Dennis Ritchie, or K&R as the book and its authors are affectionately known. (The second edition was published in 1988 by Prentice-Hall, ISBN 0-13-110362-8.) These notes are now (as of Winter, 1995-6) intended to be stand-alone, although the sections are still cross-referenced to those of K&R, for the reader who wants to pursue a more in-depth exposition.

---

Chapter 1: Introduction

Chapter 2: Basic Data Types and Operators

Chapter 3: Statements and Control Flow

Chapter 4: More about Declarations (and Initialization)

Chapter 5: Functions and Program Structure

Chapter 6: Basic I/O

Chapter 7: More Operators

Chapter 8: Strings

Chapter 9: The C Preprocessor

Chapter 10: Pointers

Chapter 11: Memory Allocation

Chapter 12: Input and Output

Chapter 13: Reading the Command Line

Chapter 14: What's Next?

---

Read Sequentially

Memory Allocation

[source: http://www.eskimo.com/~scs/cclass/notes/sx11.html]

In this chapter, we'll meet malloc, C's dynamic memory allocation function, and we'll cover dynamic memory allocation in some detail.

As we begin doing dynamic memory allocation, we'll begin to see (if we haven't seen it already) what pointers can really be good for. Many of the pointer examples in the previous chapter (those which used pointers to access arrays) didn't do all that much for us that we couldn't have done using arrays. However, when we begin doing dynamic memory allocation, pointers are the only way to go, because what malloc returns is a pointer to the memory it gives us. (Due to the equivalence between pointers and arrays, though, we will still be able to think of dynamically allocated regions of storage as if they were arrays, and even to use array-like subscripting notation on them.)

You have to be careful with dynamic memory allocation. malloc operates at a pretty ``low level''; you will often find yourself having to do a certain amount of work to manage the memory it gives you. If you don't keep accurate track of the memory which malloc has given you, and the pointers of yours which point to it, it's all too easy to accidentally use a pointer which points ``nowhere'', with generally unpleasant results. (The basic problem is that if you assign a value to the location pointed to by a pointer:

 *p = 0; 

and if the pointer p points ``nowhere'', well actually it can be construed to point somewhere, just not where you wanted it to, and that ``somewhere'' is where the 0 gets written. If the ``somewhere'' is memory which is in use by some other part of your program, or even worse, if the operating system has not protected itself from you and ``somewhere'' is in fact in use by the operating system, things could get ugly.)

11.1 Allocating Memory with malloc

11.2 Freeing Memory

11.3 Reallocating Memory Blocks

11.4 Pointer Safety