I've had a look at the asm file. I've compiled this code as a test: 1: counter=217 2: in_a=85 3: pata_hd_sector_buffer_lo[counter]=in_a 4: pata_hd_sector_buffer[counter]=in_a
The third line translates to 6 assembler instructins. The fourth line translates to 5 instructions plus a call to l__large_array_3_put, which is from 19 to 24 instructions, depends on the field index. 2 instruction cycles each for call and return, sums up to 27 to 32 instruction cycles to set a value in the large_array. So writing or reading a value in a large_array takes roughly five times as long as in a simple array. I don't say large_array is in general bad, it's great for filenames or the like. But to get code run fast, it's important to get speed to the innermost functions. On highest SPI speed, it takes 8 instruction cycles to get a byte from an SD card. So, large_array does also slow down SD card reading, I think. >From the speed tests you can see that the sector_buffer, when organized as two >simple arrays of 256 bytes each, saves code space, data space, and execution >time for PATA and probably also for SD. Reading and writing can easily be done >with simple auxiliary functions. That's why I propose changing the data format. Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
