- Performance of unaligned memory-accesses - 7 Updates
- Lock-free LRU-cache-algorithm - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 11 11:46PM +0200 > That's stupid. Some compilers might rely on the emulation, some > compilers might do the disassemby and assembly of the data-word > themselfes. And as I told the Oracle C/C++ compiler on solaris can do both. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 11 11:44PM +0200 > First, I did not say that no OS emulates unaligned accesses - > I said that you were wrong to say that /every/ OS did so, ... I didn't say that every OS does this. > ..., and I challenged you to find a reference to even /one/ > example that does. The lattter link to the example with Solaris is a reference on that. > Secondly, I said that no compiler would rely on OS emulation for > unaligned /packed/ field access. That's stupid. Some compilers might rely on the emulation, some compilers might do the disassemby and assembly of the data-word themselfes. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 12 06:24PM +0200 Am 12.08.2019 um 18:22 schrieb Öö Tiib: >>> even though there likely won't be for a single object. >> No, the structure-size is rounded up for that. > Not when #pragma pack(1) is used like they discussed. ... There wasn't any #pragma pack in the former example. |
| Keith Thompson <kst-u@mib.org>: Aug 12 09:33AM -0700 >> No, the structure-size is rounded up for that. > Not when #pragma pack(1) is used like they discussed. It will > erase such padding. And the quoted (but not attributed) text was a correction to an earlier statement of mine. In context, the presence of #pragma pack(1) was clear. (I won't respond directly to Bonita as long as she inists on deleting attribution lines.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Melzzzzz <Melzzzzz@zzzzz.com>: Aug 12 07:13PM >>> but because the CPU and / or OS might not support this at runtime. >> Accessing char is not undefined behavior. > You might be stupid, but that not stupid. Sure, give example of unaligned access to char. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 12 09:15PM +0200 >>> Accessing char is not undefined behavior. >> You might be stupid, but that not stupid. > Sure, give example of unaligned access to char. No, everyone can guess from the "0x3" that pI points to a 32 bit integer - exept you. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Aug 12 07:25PM >> Sure, give example of unaligned access to char. > No, everyone can guess from the "0x3" that pI points to a 32 bit > integer - exept you. No it can't. pI can point to anything. But I even don't look into that. I comment assertion that unaligned access is undefined behavior, which is not always true. eg you can cast to char* and access anything. You can use memcpy to copy contents as well. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 12 07:48PM +0200 I just found this article: https://en.wikipedia.org/wiki/Page_replacement_algorithm It it a good starting-point for this issue. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment