A read from or write to memory on a 32bit machine is done at 4 byte per cycle , if I have an integer and a long double variables assigned with some values, then how many cycles does it take to read/write them ? Does it make any difference if I use these variables on different platforms et machines ? Thank you.
-
1 cycle for `int` and 2 cycles for `long double` ? – iammilind Aug 23 '11 at 05:08
-
Thanks, but if the test asks me to calculate it in case of a char and a double ? – Dalton Aug 23 '11 at 05:13
-
1double is 8 bytes and character is 1, do the math? character actually takes more than 1 cycle because of the need to align it to 4 bytes to do the operation which involves sign extend/zero extend and other things – Jesus Ramos Aug 23 '11 at 05:15
-
So you mean it is 3 cycles in total ? – Dalton Aug 23 '11 at 05:19
-
for unaligned char it takes 2 cycles one to prep the value and another to do an aligned store/read – Jesus Ramos Aug 23 '11 at 05:45
-
32-bit machines haven't worked this way for well over a decade. You need to do your homework with the machine that your teacher described. – Hans Passant Aug 23 '11 at 05:55
-
@Jesus The homework doesn't mention any alignment. How can you make assumptions about a fictional CPU from a homework question? You can't know how many cycles does it take for a fictional CPU to fix it's possible alignment... – Lundin Aug 23 '11 at 06:22
-
@Lundin you're right I was assuming standard architecture when I probably shouldn't be – Jesus Ramos Aug 23 '11 at 06:36
4 Answers
Find out how how many bytes is the integer and the long double in your case. Then use the rule of three to compute how long it takes.

- 17,697
- 6
- 59
- 114
-
I don't know what the rule of three is in this context (in my mind it has to do with constructors and destructors in C++). – Michael Burr Aug 27 '11 at 10:12
On x86 32 bit sizes are as such Integer 4 bytes, long double is actually 16 bytes (at least it should be, on some arch's its 8 bytes and on others 12 bytes) and each cycle can only operate on 4 bytes at a time so Integer takes 1 cycle and long double takes 4 (3 and 2 respectively for the other sizes mentioned) cycles. On 64 bit machines with SSE instructions can do 16 bytes in one or two cycles.

- 22,940
- 10
- 58
- 88
-
SSE takes two double (not even long double) and performs an operation on them in 1 cycle. It cannot handle long double. – Daniel Aug 23 '11 at 05:47
-
64 bit SSE can handle up to 16 bytes at once regardless of type hence long double fits in that range (unless for some odd reason long double > 16 bytes) – Jesus Ramos Aug 23 '11 at 05:49
-
No it doesn't. SSE takes 16 byte input but it operates on each half of it parralely as a separate double, it never treats more that 8 byte as a number. – Daniel Aug 23 '11 at 06:02
-
Still a compiler can never fit long double into SSE and can never use 128 bit floating point in SSE. – Daniel Aug 23 '11 at 06:07
-
-
FWIW, on 32 bit x86, long is 32 bit, 4 bytes, while long long is 64 bit, i.e. 8 bytes, and long double (extended) is 80 bit, or 10 bytes in size. Due to alignment, long double usually requires 16 bytes, indeed. But ***SSE won't do long double***. It can do two doubles at most. – Rudy Velthuis Aug 23 '11 at 06:50
-
@Rudy SSE can operate on long double provided they are stored on the stack – Jesus Ramos Aug 23 '11 at 07:21
-
@Jesus: no, SSE can't. The largest type it will handle is double. The x87 FPU can handle a long double (80 bit). SSE can't. And it doesn't matter where it is stored. Or did you mean the FPU stack? Well, only the FPU has an FPU stack. SSE doesn't. – Rudy Velthuis Aug 23 '11 at 14:07
-
@Rudy I thought gcc's implementation of floating point placed long doubles on ST0 and ST1 using the 16 byte moves (although operations are split) – Jesus Ramos Aug 23 '11 at 19:11
-
@Rudy I was correct, moving a long double is done using SSE MOV instructions as it can move 16 bytes at once so in this case for read and writes it works. – Jesus Ramos Aug 25 '11 at 02:15
-
@Jesus: You can ***move*** any kind of memory with SSE, but you can't process a long double (do FP math on it) with SSE. Big difference. – Rudy Velthuis Aug 25 '11 at 06:32
-
@Jesus: the FPU stack is a set of registers. I doubt you can simply **move** something there using SSE. You use `fld` or similar to do that, IOW, only the FPU can load items onto its internal stack. – Rudy Velthuis Aug 25 '11 at 06:50
There's a good question on this topic found here: long long implementation in 32 bit machine The highest rated response has insights into how they're stored, and operated upon as well.
Since I don't know what architecture you're referring to, and since it's just homework, I am tempted to say it'll take two mov
instructions to perform storing a long long integer. And thus, two cycles.

- 1
- 1

- 12,609
- 8
- 54
- 101
Integer = 4 byte, long double = 10 byte which means integer = 1 cycle long double = 2.5(3?) cycles.

- 30,896
- 18
- 85
- 139
-
-
-
-
-
if you have a 10 byte read/write it would take an additional cycle to do a sign/zero extend. the only non aligned primitive is character which is 1 byte. long double depending on system is either 8, 12, or 16 bytes – Jesus Ramos Aug 23 '11 at 05:23
-
@Jesus Ramos, it's 80 bit using the floating point extended mode, read http://en.wikipedia.org/wiki/Long_double. – Daniel Aug 23 '11 at 05:38
-
-
@Jesus: a long double (extended) is a type supported by the Intel FPU, and it is 80 bits or 10 bytes. It is usually aligned on a 16 byte boundary, but it is only 10 bytes in size. And there is no need to zero extend anything: it is a floating point type, you don't zero extend those. And this hardly depends on the system. – Rudy Velthuis Aug 23 '11 at 06:54
-
@Rudy there are flags that you can use to set the alignment boundary for a long double – Jesus Ramos Aug 23 '11 at 07:18
-
@You say it hardly depends on the system but the system is the one that determines the boundary, on this particular version of Arch Linux the alignment is 12bytes but on my BSD machine it is 16 bytes and they both have the same processor. – Jesus Ramos Aug 25 '11 at 13:14
-
@Jesus Ramos: It depends on the binary interface. in elf file format (Linux) you can specify the alignment, but its usually 4 bytes. so either BSD using a 8/16 byte aligned format or your compiler/linker is choosing big alignment. – Daniel Aug 25 '11 at 14:01