You are correct in your interpretation of how the SHARC works. It is not a byte-addressable architecture, and all data elements are treated as 32-bit entities. From the SPI perspective on the SHARC side, the data would be populated in memory in sequential 32-bit locations, but only the lower 8 bits would contain the data because your SPI data width is set to 8. So, if the ARM treats char as 1-byte and short as 2-byte, and data is transmitted LSB first, then the above structure would come across to the SHARC and be stored in memory as:
rcv_buf[0] = magic.lower
rcv_buf[1] = magic.upper
rcv_buf[2] = type.lower
rcv_buf[3] = type.upper
rcv_buf[4] = num
...
rcv_buf[n-7] = data[0]
rcv_buf[n-6] = data[1]
rcv_buf[n-5] = data[2]
rcv_buf[n-4] = data[3]
rcv_buf[n-3] = data[4]
rcv_buf[n-2] = data[5]
rcv_buf[n-1] = data[6]
rcv_buf[n] = data[7]
Each of the above buffer elements would be a right-justified, 0-filled, 32-bit entity. You would then need to have software appropriately pack the received short data into a single element before processing it. Another alternative would be to use 16-bit SPI width, which would natively accommodate the short data (again, assuming it is 16-bit), but that would require that you insert a zero byte after each char in the structure.