[ekg2-devel] Pola zamiast act w window_t

[Jakub Zawadzki]

On Sun, Feb 10, 2008 at 01:38:52PM +0100, Michał Górny wrote:
> On Fri, Feb 08, 2008 at 05:29:16PM +0100, Jakub Zawadzki wrote:
> > W sumie racja, /me myslal o polach bitowych zeby nie popsuc ABI, a to
> > w koncu niepotrzebne.
> > 
> > Wiec mozna olac pola bitowe, i mozna zrobic na calym int.
> 
> Hm, 32 bajty ??? dobrze liczę?

Tak.
Wszedzie masz inty, nawet jakby wystarczyl char, chcesz zmieniac?
(W koncu char zajmuje 8 bajtow)

i w ogole Choblika!, nie moja wina ze procesor lubi wyalignowane dane do rozmiaru slowa,
i ze jak mu sie takie daje, to jest najbszyciej.

> > Zamianie wszedzie raczej bym sie wstrzymal, ale to jest do dyskusji.
> > (W koncu korzystamy wszedzie z int)
> > 
> > Rozmiar struktury window_t jest malo wazny.
>
> Może i na zbawienie pamięci użytkownika to nie wpłynie, ale różnica jest.
> 
> - przed (tzn. jak było oryginalnie, wspólny int dla flag):
> 	(gdb) print sizeof(window_t)
> 	$1 = 104
> 
> - po:
> 	(gdb) print sizeof(window_t) 
> 	$1 = 80 

Jeszcze jest wazne jak libc to wyrownuje:

Aktualnie: 
(gdb) call -( malloc(sizeof(window_t))-malloc(sizeof(window_t)) )
$1 = 112

> (amd64, -O0)
amd64, -O2 -g :)

Tia, ale ile masz tych okien? Kod wygenerowany przez gcc ktory to przesuwa pewnie jest porownywalny :)
[dzolk]

Mnie sie najbardziej w polach bitowych nie podoba, jak jest: (przyklad z zycia wziety)
	struct { 
		/* ... */
		unsigned int bold:1;
		/* ... */
	} smth;

[zakladamy ze attr zawiera FSTR_BOLD]

i robisz na nim przypisanie:	smth.bold = (attr & FSTR_BOLD); 	smth.bold == 0
			vs	smth.bold = (!!(attr & FSTR_BOLD));	smth.bold == 1

szukanie bledu, srednio przyjemne.

Ogolnie pewnie oba rozwiazania sa b. podobne wydajnosciowo, wiec jak dla
mnie mozesz nakladac ta latke, ale jak to cos psuje, to bedzie na Ciebie (patrz blad wyzej) :)

Pozdrawiam.