NASM Syntax issue

Programming, for all ages and all languages.
Post Reply
adw3221
Posts: 18
Joined: Thu Aug 31, 2006 11:02 am

NASM Syntax issue

Post by adw3221 »

(I feel this should go in the General Programming forum)
For my OS I'm writing a macro for the IDT table so when the kernel gets bigger/changes significantly I won't have to go back and update the hard coded addresses.

The macro only takes one parameter and that is the offset. (I'll add more when I get into user mode applications) The ISRs themselves are stored elsewhere and all I have is a symbol definition ([extern someplace]).

This is my macro code so far:

Code: Select all

%macro addid 1 
	dw %1			
	dw 0x8					
	dw 0x8E00
        dw (%1) >> 16			
%endmacro
I read that I should put the brackets around the bottom %1 because it tells NASM that the value will be modified.
In the DATA section of code that loads the IDT I have the IDT itself and it looks like this:

Code: Select all

	idt:
		addid [exceptdivide]
and so on.
When I assemble it I get this:
34: error: expression syntax error
34: error: expression syntax error
Any ideas how to fix this?
User avatar
XCHG
Member
Member
Posts: 416
Joined: Sat Nov 25, 2006 3:55 am
Location: Wisconsin
Contact:

Post by XCHG »

[exceptdivide] is a variable and you can not have a macro (neither in NASM nor in any other assemblers) that accepts a variable and then does calculations on its value and then assigns it to another variable.

I used your macro and passed the value 3 to it. It worked! You can pass any constant 16-bit values to it (because you have defined a DW label) and it will work. As soon as you pass the value of a variable (when you push the variable inside square brackets, that will be the value of the variable and not its address), NASM will nag at you.

If you even remove the square brackets, NASM will still give you another error. Look below; the first time that I used your macro is when I passed a constant value to it and you can see that it assembled my kernel. Then I passed a variables' value using square brackets and I got the same exact error as you get. Then I removed the square brackets and then came the last error:

Code: Select all

C:\Kernel>nasm -f bin kernel.asm -o kernel.o

C:\Kernel>nasm -f bin kernel.asm -o kernel.o
kernel.asm:84: error: expression syntax error
kernel.asm:84: error: expression syntax error

C:\Kernel>nasm -f bin kernel.asm -o kernel.o
kernel.asm:84: error: shift operator may only be applied to scalar values

Cutting the story short, you must pass a constant value to your macro.
On the field with sword and shield amidst the din of dying of men's wails. War is waged and the battle will rage until only the righteous prevails.
adw3221
Posts: 18
Joined: Thu Aug 31, 2006 11:02 am

Post by adw3221 »

Alright, but passing constants might be a little tedious since its part of my IDT.
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

Why do you not generate the IDT during run-time?
adw3221
Posts: 18
Joined: Thu Aug 31, 2006 11:02 am

Post by adw3221 »

Well that would suck up execution time and the like.
User avatar
Kevin McGuire
Member
Member
Posts: 843
Joined: Tue Nov 09, 2004 12:00 am
Location: United States
Contact:

Post by Kevin McGuire »

Code: Select all

bits 32
%macro dyaddid 2
	mov ebx, %1
	mov word [eax+%2*8+0], bx
	mov dword [eax+%2*8+2], 0x008E0800
	shr ebx, 16
	mov word [eax+(%2*8+6)], bx
%endmacro

align 8
idt_table: resb (8 * 256)

align 4
my_idt_function1:
	hlt
my_idt_function2:
	hlt
my_idt_function3:
	hlt
my_idt_function4:
	hlt

main:
	mov eax, idt_table
	; <function>, <index>
	dyaddid my_idt_function1, 0
Or, just make a table and do a loop across it while over writing each eight byte unit with the IDT entry if you really wanted to save space and be pretty fast about it.

Code: Select all

align 8
idt_table:
dd function1   ; resolved during link time
dd 0
dd function2
dd 1
dd function3
dd 2
dd function4
dd 3
SpooK
Member
Member
Posts: 260
Joined: Sun Jun 18, 2006 7:21 pm

Post by SpooK »

Mike359 wrote:Well that would suck up execution time and the like.
Kevin is on the ball about that.

Execution time is only one factor. How long do you think it takes to fetch data from RAM to the L2/L1 caches when such handling code is scattered???

You will find that the few hundred or thousand clock-cycles you waste is worth the reduction in redundant handling code. You sacrifice 1KB to save 20KB.

As an added bonus, imagine the reduction in bug-chasing if you only had to monitor one interrupt entry procedure ;)
Post Reply