16+16 != 32 (gcc, linux)

Thread View: pl.comp.lang.c

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by slo... Tomasz Slodkowicz Fri, 10 Oct 1997 00:00

#47

Author: slo... Tomasz Slodkowicz
Date: Fri, 10 Oct 1997 00:00

68 lines
2594 bytes

No wlasnie, dokladnie tak: 16 bitow + 16 bitow != 32 bitow...

Ale po kolei. Przenosilem program dosowy pod linuxa. Caly dzien walczylem ze
zrodlami jadra (gdzie znalezc specyfikacje tych roznych ioctl dla roznych
urzadzen???) i wreszcie program zaczal jakos dzialac (nie bylo to latwe,
troche brakuje asemblera pod linuxem z inb, outb itp).

Dane zwracane - teraz juz przez jadro - ogladalem poprzez zdefiniowana
strukture. I tu zaczely sie klopoty...

struct xxxx {
  unsigned :3;
  unsigned :4;
  unsigned :1;
  unsigned char [6];
  unsigned ;
  unsigned long;
} tak mniej wiecej wygladala pod dosem.

Oczywiscie (?) pojawily sie smieci, choc dane zwracane byly dobre.
Po pierwsze dosc szybko znalazlem (w limits.h) ze int w gcc ma 32 bity,
wiec zmienilem unsigned  na unsigned short...

Od razu sie poprawilo, ale od pewnego miejsca dalej byly bledy. Dlugo
szukalem co to, ale w koncu znalazlem. Pierwszy wystepujacy w strukturze
skladnik long zawieral dane:

 0xSSSSHHHH (0xLLLL) S - smieci, H - bardziej znacz. slowo, L - mniej
            ^^^^^^^ to tutaj to nastepne bajty w strukturze

Czyli bylo cos przesuniete... Myslalem ze cos skopalem (dodalem jakies dane
do struktury), ale nie. Poza tym, gdyby to bylo tylko przesuniete, to bylo
by  ssss LLLLHHHH (w i386 sa odwrocone kolejnosci slow, bajtow...)

Okazuje sie, zapisy:

  unsigned short [2];      i    unsigned long ;

pomimo ze maja tyle samo bitow (32) zwracaja rozne dane!!! Nie chodzi tu tez
o wyrownanie adresow (bo w innej kolejnosci sa slowa).

Teraz dziala to tak, ze :

unsigned short a[2];
unsigned long b;

*(unsigned long *)(&a) daje poprawne dane, a b zle...

Nie rozumiem o co tu moze chodzic...
Albo pokazujac inaczej:

W pamieci:       aa bb cc dd ee ff gg (hex)
2xshort:         --i-- --j--
1xlong           -----l----- --k--

to *(unsigned long*)(& i) == 0xddccbbaa
a                      l  == 0x####ddcc (przy czym k == 0xffee)

Co z tym zrobic? Czy tak ma byc? Jak to obejsc?

Tomek

--
  Tomasz Slodkowicz   Institute of Computer Science
                      Jagiellonian University, Cracow, Poland
  e-mail: slo...@ii.uj.edu.pl
  www   : http://www.ii.uj.edu.pl/~slodki

Re: 16+16 != 32 (gcc, linux)

#48

Author: Cezar Cichocki
Date: Fri, 10 Oct 1997 00:00

17 lines
875 bytes

VTAM!

Tomasz Slodkowicz <slo...@infoserv.ii.uj.edu.pl> wrote:
> No wlasnie, dokladnie tak: 16 bitow + 16 bitow != 32 bitow...

> Ale po kolei. Przenosilem program dosowy pod linuxa. Caly dzien walczylem ze
> zrodlami jadra (gdzie znalezc specyfikacje tych roznych ioctl dla roznych

np w kernel-hackers-guide.

> urzadzen???) i wreszcie program zaczal jakos dzialac (nie bylo to latwe,
> troche brakuje asemblera pod linuxem z inb, outb itp).

man 2 outb ;)

Cezar

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads