>On 2001-03-10 19:12:40, coindood wrote:
>>On 2001-03-08 21:54:35, Chris Giese wrote:
>>>On 2001-03-07 12:41:51, coindood wrote:
[setting up IRQs with GCC]
DJGPP has some functions for handling interrupts
under DOS/DPMI. GCC in general, however, has no
built-in support for interrupts, so you must use
some assembly language. Here is some skeleton
code:
http://www.execpc.com/~geezer/osd/intr/idt.asm
Watch out for these potential problems:
1. The argument to LIDT is unusual. It's the
address of a 6-byte "pseudo-descriptor". The
pseudo-descriptor contains the 2-byte IDT size
followed by 4-byte IDT linear address.
2. The IDT address in the pseudo-descriptor is a
LINEAR address. The address is not changed by by
segmentation like other addresses, so you must
translate it yourself.
3. The 32-bit handler offset in each interupt gate
is broken into two 16-bit chunks. This doesn't
work:
idt_gate_0:
dw (handler & 0FFFFh) ; bits 15-0 of offset
dw CODE_SEL ; selector
db 0
db 8Fh ; access byte
dw (handler >> 16) ; bits 31-16 of offset
NASM chokes on the shift (>>) operation. So, you
must build the IDT at run-time. This is not
difficult.
4. The BIOS programs the interrupt controller
chips (the 8259s) so that IRQs 0-7 use some of
the "reserved" interrupts. (This was a mistake
by IBM when they designed the PC.)You should
re-program these chips; maybe like this:
http://www.execpc.com/~geezer/osd/intr/8295.c
>I am using gcc, and one last thing, how do you get headerfiles
>to get included? the only way I got them to work was to compile
>them into .o files and link them in. I know it sounds stupid, but
If it works, it's not stupid
The .h files should not contain any function
bodies or variable declarations. Everything that
occupies memory (function bodies and global
variables) should go into the .c files. The .h
files should be #include'd, but not compiled by
themselves.
>I've been doing all the compiling and linking by hand because
>I don't know how to make makefiles well enough toactually be useable.
If your code is small and you have a fast PC, this is OK for now.
A crash course in makefiles:
1. Use macros as you would with C: to make the
file self-documenting, and to confine possible
changes to a small part of the file:
LIBOBJS =stdio.o string.o x86.o
OBJS =startup.o main.o io.o
LIBS =libc.a
LDSCR =coffkrnl.ld
LFLAGS =-T$(LDSCR)
CFLAGS =-Wall -W -I. -O2 -fno-builtin -mcpu=i486
AFLAGS =-f coff -dUNDERBARS=1
2. Use "explicit rules" for linking, and for
building libraries:
krnl.cof: $(OBJS) $(LIBS) $(LDSCR)
(tab) ld $(LFLAGS) -o$@ $(OBJS) $(LIBS)
libc.a: $(LIBOBJS)
(tab) ar rcs $@ $(LIBOBJS)
*** NOTE *** For the commands in the makefile
rules, you must use tabs at the beginning of the
line, not spaces. (Yes, this is stupid.) DO NOT
USE DOS EDIT FOR MAKEFILES.
3. Use "dependencies" plus "implicit rules" for
creating .o files:
# implicit rules
.c.o:
(tab) gcc -c $(CFLAGS) -o$@ $<
.asm.o:
(tab) nasm $(AFLAGS) -o$@ $<
# dependencies
startup.o: startup.asm
main.o: main.c
io.o: io.c
stdio.o: stdio.c
string.o: string.c
x86.o: x86.asm
*** NOTE *** GNU make doesn't recognize some
implicit rules unless you use a .SUFFIXES line
.SUFFIXES: .asm
4. If you just type "make", the first dependency
or explicit rule or "target" in the makefile will
be built. Usually, the first target is named
"all":
all: krnl.cof
Login
Register
FAQ
Search
