During development a software for embedded system and especially GPU programs, many things can go wrong, resulting board hung or filesystem crash. In such circumstances there is always a risk of a lost of source code. In order to avoid such a problem storage of the source code is recommended to be on some remote host (e.g. laptop). It is not very important what OS will be on that computer, it just should provide easy way to edit and browse source files, version control and ability to mount a folder to Raspberry-Pi.
If remote host has Linux use NFS filesystem, if it has Windows use shared folder and CIFS filesystem. Lets focus on Windows, because it is an example of cooperation of two different systems.
Establishing the connection requires following steps on Windows:

1. create designated user for remote access (e.g. pi_user),
2. create the folder that will be shared (e.g. shared),
3. setup rights to that folder for new user (grant full control over the folder),
4. enable and setup folder sharing (name the shared folder, e.g. shared-rpi),
5. check IP address.

and on Raspberry-pi:

1. create the folder where remote folder will be mounted (e.g. ~/vc4/shared-rpi),
2. create a script if you wish to mount the folder manually (if you need automatic mount add proper line to fstab)
   for example mount-win.sh,
3. add execution rights to the script
4. add pi user to sudoers

Below is an example of the mounting script that mount remote windows folder that is on computer with the IP address 192.168.0.6. Folder is mounted in home folder of pi user with proper rights for this user.

#!/bin/bash

mount -t cifs -o rw,user=pi_user,uid=pi,gid=pi //192.168.0.6/shared-rpi /home/pi/vc4/shared-rpi

In order to mount the folder execute the script and enter password of the windows user. Next, change directory to mount point and check if you see the contents of mounted folder and you can write there a file.

pi@raspberrypi:~ $ sudo ./mount-win.sh
Password for smb_access@//192.168.0.6/shared-rpi:  *********
pi@raspberrypi:~ $ cd vc4/shared-rpi
pi@raspberrypi:~/vc4/shared-rpi $ ls

   { here files should be listed that are on windows }

pi@raspberrypi:~/vc4/shared-rpi $ echo "123" > test.txt

   { now check on windows if test.txt file appeared in mounted folder and it has 123 contents }

Minimal register dump may be implemented as a macro, hence it is easy to insert it in any location in the QPU program. If you need to examine the registers, this macro can be added in some line in the source code.

When you look in macro implementation it can look like below.

The body of the macro uses two helping macros for dump of file registers (dump_regs) and writing data from VPM to SDRAM (store_dump). They perform also necessary waits in order to be synchronized with end of transfers. Full source code is avalable for download as a part of example of QPU programming project (see below) - file qasm/breakpoint.qinc.

The body of the macro (_breakpoint) writes all dumped registers (file registers and accumulators) to VPM (Vertex Pipe Memory) and stores it to the common memory with CPU. Addresses of buffers were passed via uniforms and stored in two file registers, with symbolic names: dbg_rfile_dump and dbg_accus_dump. After necessary writes that macro exits QPU program, so CPU program is released and prints the contents of the buffers in a readable form. An example of that log is presented below:

NOTE
Above register dump is for one QPU core. It consists of 2 parts: accumulators and file registers contents (rb registers are only partialy visible in this figure). Each register is printed horizontally, with consecutive 16 elements from left to right. Accumulators are printed twice, as floating point numbers and hexadecimal 32-bit integer numbers. Special purpose accumulators r4 and r5 are omitted. For each file register symbolic name is assigned and format of the data is specified in application.

In this case, incremental aproach to programming means that you start from a program for single QPU and small part of data and incrementally scale up to multiple QPU cores and large data.
At the first phase you can develop the program in assembler, examine the QPU processor specific behavior. If it is your first program for the QPU, for sure you will see that some instructions work different that you thought. You will discover that some combinations of arguments are invalid, so the instructions are not so flexible one could expect. There are also some dependencies between consecutive instructions that you need to guard, otherwise result will be incorrect (e.g. written file register not available in next instruction).
This is also debug phase, when you correct the code. It will be not very difficult if you use registers dump. The code may be optimized here, especially by using dual-issue architecture of ALU.
In next phase add a loop, that processes next bunch of input data. Macro that dumps registers terminates the QPU program, so its not good for debug loop behavior. Nevertheless it is possible to workaroud that weakness. Copy the code in the loop, so you have the first and second loop iteration in different location. In that way you will be able to examine loop behavior (i.e. to check if loop variables are correctly changed from one iteration to another).
Now will be harder, you need to switch from one QPU program, to multiple QPUs. Start from the program for two QPUs, when it works extend it for more QPUs. Keep in mind that you need one program for all QPUs, there will be variations but the code should be one - QPU instruction cache memory has limited size!
Start from assigning different parts of data for each QPU. New item in this program will be a synchronization between cores. Learn how it is done in example.
Here results should be written into VPM and after all QPU cores finished, to common memory with CPU. In this way they will be available for verification.

Links