PLease help - confused about some ambiguous namings and such

[DeReiter]

OK. A byte is 8 bits. What is word? 2 bytes? 4 bytes?

Why does alignment matter? .align  4  aligns on a 32 bit boundary...What does .align 2 do?

Should I align my GDT table?

For gas - what does .long mean? .comm?

If say I want to define the GDT structure in C - I know that char - byte, int - (word?)

So is word a 32-bit entity? 4 bytes? Then what is 2 bytes?

i am sooo confused...

[DeReiter]

Also.... what and (how) to 4 KB align? Allright, I am a newbie....but still

[DeReiter]

How do I access and edit) my GDT table from C?

I already did this: .globl EXT_C(gdt) <-- descriptor

[carbonBased]

A word is _either_ 2 bytes _OR_ 4 bytes... and, I suppose, in newer architectures, 8 bytes.  It's a rather odd (and stupid) system.  Depends on what platform you're on.

I believe, technically, a word is simply a group of bytes.

On Intel architecture it's _generally_ considered 2 bytes (and almost exclusively in assembly -> dw = define word = define two bytes).

Again, on Intel architecture, a dword (or double word) is 4 bytes.

Alignment matters because of the nature of the beast... if you try and load a dword from a non-dword aligned address it's _slow_.  Same thing happens loading a word from a non-word aligned address.  It's just one of those things the Intel processor's been optomized for, and when it encounters something like that, it stalls... screws with its pipelines and what-not

.align x aligns to x bytes, therefore .align 2 aligns to a word address.

YES, align your GDT, and IDT, and any LDTs you might have!

.long defines a dword, or 4 bytes:
.long 0x11223344

.comm puts a data element into the "common" section.  It's a special linker section where by, if a duplicate definition exists, you wont get an error, but definitions will simply merge to the same location.  Usefull for stacks and what-not.

char = byte
That's all you know in C   C's definitions are ambiguous.
In most 16-bit compilers, int = 16-bits (2 bytes), while
in most 32-bit compilers, int = 32-bits (4 bytes)

_Typically_ (although even this isn't always true)
short = 16 bits
long = 32 bits
This is how GCC (and therefore DJGPP) work, btw.

Hope that helps,
Jeff

[carbonBased]

Remember, .align x aligns to x bytes, right?

So, 4KB = 4096 bytes = 0x1000
so .align 0x1000 should work.

Jeff

PS: the nature of .align is platform specific, the above is stated for i386 using ELF.  i386 using A.OUT is slightly different (but outdated... you should be using ELF

[carbonBased]

Try this:

struct {
  long one;
  long two;
} GDT_Entry;

GDT_Entry *myGdt = (GDT_Entry *)gdt;

Then you can access number n descriptor as myGdt[n].whatever

Jeff

PS: You'll want to actually change the GDT_Entry structure to actually reflect a real GDT element, not just one, two   I don't have that info on me at the moment, unfortunately.

[DeReiter]

Thanx a lot for you help

[DeReiter]

So since the GDT entries are 32-bit (dwords) I should .align 4
Same ges for the GDT descriptor because we can treat it as 2 dwords? Right?

Thanx again for all your help...

[DeReiter]

I define the IDT and initialize it from within my C code - any tricks
to make sure it is aligned? I mean I realize that if I can allocate 4KB pages - they are
obviosuly aligned and i can use them for the IDT - but so far I plan to use
the BogoMalloc by Geezer....

[carbonBased]

GDT entries are two dwords long, so you'd want to _at least_ .align 4

You might want to .align 8, but I don't know if that'll make any difference.  4 bytes should be enough... especially if you're, like most, only using a few selectors (meaning there'll be very few loads from the GDT).

Jeff

[carbonBased]

If the address is aligned to a dword, then
address & 3 = 0

newAddr = address & !3
Will dword align an address, however, it also has the possibility of occupying up to three bytes _before_ address (which might overwrite other things).

If you allocate 3 extra bytes in your alloc, you can try the following:
newAddr = address + (4 - (address & 7))

Which will dword align an address.  It will waste (at most) 3 bytes, but since you actually allocated those bytes, you wont be overwritting anything essential.

However, keep in mind that GCC, with any form of optimization enabled, will dword align everything... I don't know about BogoMalloc, but you might want to check it's code.  It may return dword aligned address anyway.

Jeff