Page 1 of 1
anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 4:22 am
by ggodw000
To aid in my debugging, I defined M_PRINTF macro that I use throughout my code. To further enhance it, I was wondering to see if there is a way to determine the proc name through manipulation of any of the pre-defined macro or any other means, so that, as of now, I can call M_PRINTF macro with string:
and it prints out following output
If I can automatically get proc name, so that when M_PRINTF macro called from any procedure, it is able to print something as follows:
Code: Select all
<procName>: Blah blah
<procName1>: Helloworld
when it is called from following proc-s:
Code: Select all
<procName> proc far
....
M_PRINTF "\nBlah blah"
....
<procName> endp
<procName1> proc far
....
M_PRINTF "\nHelloworld"
....
<procName1> endp
Sure, you can type manually in every M_PRINTF statement but that is huge maintenance nightmare, tedious and prone to errors and omissions.
I did this exactly in python using one of the python library, printing out calling function name in prefix automatiicaly with any print out is huge debugging clarity and assistance.
So far I looked through most comprehensive ASM X86 manual and looked through pre-defined macros so far, not finding anything.
Thanks.,
Here is my M_PRINTF macro which you can use to print any string on the fly without defining it on data segment and pass pointers to it:
it can currently process new line chars but i am planning to enhance further too:
Code: Select all
M_PRINTF MACRO pStr
local skipStr, printfLoop, exitMacro, printfStr, m_printf_skip_esc_char
IF OPTION_ENABLE_M_PRINT
push ax
push dx
push bp
push cx
jmp skipStr
printfStr db pStr, '$'
skipStr:
lea bp, cs:printfStr
mov cx, 3h
printfLoop:
mov ah, 02h
mov dl, cs:[bp]
cmp dl, '$'
je ExitMacro
cmp dl, '\'
jne m_printf_skip_esc_char
cmp byte ptr cs:[bp+1], 'n'
jne m_printf_skip_esc_char
inc bp
mov dl, 0dh
mov ah, 02h
int 21h
mov dl, 0ah
mov ah, 02h
; int 21h
m_printf_skip_esc_char:
int 21h
inc bp
dec cx
; jz exitMacro
jmp printfLoop
exitMacro:
pop cx
pop bp
pop dx
pop ax
ENDM
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 5:30 am
by iansjack
Is a macro that calls DOS interrupts really useful in OS development? Or are you concerned here with just general purpose DOS programs?
Also note that your macro may trash the flags register, so it should be used with that in mind.
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 5:30 am
by alexfru
Is there a way to at least get the line number if not the procedure name?
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 11:22 am
by Octocontrabass
What assembler are you using? This kind of thing is specific to the assembler, and really has nothing to do with x86 at all.
NASM and YASM have the __FILE__ and __LINE__ macros, if that helps.
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 11:54 am
by ggodw000
yes it might trash flags register, i need to take care of it.
i am using masm32.
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 12:49 pm
by ggodw000
iansjack wrote:Is a macro that calls DOS interrupts really useful in OS development? Or are you concerned here with just general purpose DOS programs?
i guess both. i am mostly writing in DOS to do some tools and experimental programs. so would be useful for some time.
can it be used in O/S dev? Can i use it while still in protected mode? that is million dollar question. I assumed yes once IDT initialized (which I am stil tackling) however i could be terribly wrong.
...currently i am launching my would-be kernel from DOS. later on, i will make it directly bootable but not a concern for now.
so dos interrupts 21h means, once DOS boots it installs those on IVT? if i boot directly without booting DOS, those int 21h will not be available?
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 1:27 pm
by Octocontrabass
ggodw000 wrote:i am using masm32.
Google says @FileName and @Line in MASM are roughly equivalent to __FILE__ and __LINE__ in NASM/YASM.
ggodw000 wrote:can it be used in O/S dev?
Only while you still have DOS. Once your OS loads without DOS, you can't use it anymore.
ggodw000 wrote:Can i use it while still in protected mode?
No. It only works in real mode. Once you're in protected mode, you'll have to write your own code to display information on the screen.
ggodw000 wrote:so dos interrupts 21h means, once DOS boots it installs those on IVT? if i boot directly without booting DOS, those int 21h will not be available?
Yes.
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 4:13 pm
by ggodw000
thanks!!!
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 7:41 pm
by ggodw000
would you mind giving technicalities/backgrounds on how int 21h DOS call will not work on full protected mode?
Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)
Also assuming that I will fully functional IDT which has translated every interrupt vector (total of 256) from IVT in real mode.
The only reason, I am going to pmode is to enough memory so that I can load as many exec.binary into memory as I wish, I actually contemplated using big-real mode but it is said big real mode can still not allow the CS to go above 64K so that will not work.
Thanks.,
Re: anyway to get proc name through macro or other means
Posted: Fri Jan 08, 2016 9:07 pm
by Brendan
Hi,
ggodw000 wrote:Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)
Except, for most "modern" implementations of DOS (and things like "DOS inside Windows"), DOS either isn't in real mode at all, or isn't in real mode all of the time (e.g. various memory managers, like EMM386 that comes with MS-DOS, use protected mode internally). To work around that (for DOS applications that need protected mode) there were 2 APIs - one called
VCPI and another called
DPMI (which may or may not be built on top of VCPI).
The end result of all this is that you'd have to deal with multiple cases (and multiple work arounds with different APIs); and it's far easier to boot from "raw BIOS" than to put up with all the nonsense involved in attempting to boot from DOS in a reliable way.
Once you add the fact that the only benefit you get from using DOS is support for a crippled and antiquated file system that has poor performance, poor features, insane limitations and no security at all (that should never even be considered for any vaguely useful OS's main/root file system in the first place), the entire idea starts to look "incredibly less than smart". Then you add the fact that most potential end users haven't even seen a copy of DOS for about 20 years, and the idea ends up being more like "festering plague of idiocy".
Cheers,
Brendan
Re: anyway to get proc name through macro or other means
Posted: Sat Jan 09, 2016 1:40 am
by ggodw000
Brendan wrote:Hi,
ggodw000 wrote:Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)
Except, for most "modern" implementations of DOS (and things like "DOS inside Windows"), DOS either isn't in real mode at all, or isn't in real mode all of the time (e.g. various memory managers, like EMM386 that comes with MS-DOS, use protected mode internally). To work around that (for DOS applications that need protected mode) there were 2 APIs - one called
VCPI and another called
DPMI (which may or may not be built on top of VCPI).
The end result of all this is that you'd have to deal with multiple cases (and multiple work arounds with different APIs); and it's far easier to boot from "raw BIOS" than to put up with all the nonsense involved in attempting to boot from DOS in a reliable way.
Once you add the fact that the only benefit you get from using DOS is support for a crippled and antiquated file system that has poor performance, poor features, insane limitations and no security at all (that should never even be considered for any vaguely useful OS's main/root file system in the first place), the entire idea starts to look "incredibly less than smart". Then you add the fact that most potential end users haven't even seen a copy of DOS for about 20 years, and the idea ends up being more like "festering plague of idiocy".
Cheers,
Brendan
Yes, I totally understand, what I am doing is totally antiquated, it is 16-bit asm programming! However, I am not doing it to present and sell it to people, it is totally for learning. That being said, goal of my project was to design very minimal kernel that is able to load multi binary and implement multitasking kernel basis initially, once I get behind, I will perhaps discover and learn what the limitations is and may be work on to improve and optimize. So far, i can not even get started since it derailed several times, had to get pmode working and still need to get it working with the interrupt. Last few weeks it also had derailed and had to implement complete memory management module (that was going to be required anyways). So now, I'd rather not get bogged down on writing another video module if possible, rather would like to use easier approach on this aspect and use either DOS or BIOS services for it.
.
So that is reason, for now, i am launching it from DOS for now. Now once launching from DOS, I am not loading any memory management, the kernel will take everything on its own at least in terms of memory. But for video services, would like to use int 21h if possible, if not what do you think of int10h BIOS services? I remember using int 10h, and if I remember corretly, it was bit more pain in the *ss
than using int 21h. As long as it is technically possible to use either of these services from p-mode, I'd mind about the technical limitation and performance issues for now. If not, I was asking on technicality and how and why it would not work, in which case, I'd have no choice, well may be start working on some type of video module.
Now to spill my gut, this is the 2nd time i jump starting my project. few years down the road, i did all in real mode (that was the way university class has taught), but since there are just 1mb available only in real mode, the kernel will fail as soon as loads 2-3 loadable binary to do a task switch due to memory wrap-around.
Re: anyway to get proc name through macro or other means
Posted: Sat Jan 09, 2016 1:42 am
by alexfru
ggodw000 wrote:would you mind giving technicalities/backgrounds on how int 21h DOS call will not work on full protected mode,
They will work or will not work in exactly the same way as any other real-mode interrupts/code in protected mode. If you want both BIOS/DOS and protected mode, you need to run real-mode code in a virtual 8086 mode and you'll need to catch and reflect hardware and software interrupts belonging to that code back to that code from your kernel or whatever it is that you have. DPMI solves this.
ggodw000 wrote:Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)
Also assuming that I will fully functional IDT which has translated every interrupt vector (total of 256) from IVT in real mode.
The only reason, I am going to pmode is to enough memory so that I can load as many exec.binary into memory as I wish, I actually contemplated using big-real mode but it is said big real mode can still not allow the CS to go above 64K so that will not work.
Is it possible that DPMI is all you need? Btw, there's a ring 0 version of CWSDPMI, which will run your code in ring 0, which might be handy for some tasks.
Re: anyway to get proc name through macro or other means
Posted: Sat Jan 09, 2016 2:01 am
by ggodw000
alexfru wrote:ggodw000 wrote:would you mind giving technicalities/backgrounds on how int 21h DOS call will not work on full protected mode,
They will work or will not work in exactly the same way as any other real-mode interrupts/code in protected mode. If you want both BIOS/DOS and protected mode, you need to run real-mode code in a virtual 8086 mode and you'll need to catch and reflect hardware and software interrupts belonging to that code back to that code from your kernel or whatever it is that you have. DPMI solves this.
ggodw000 wrote:Lets say for my project, it is not required to boot directly from MBR and i will be launching the loadable mini-kernel from DOS real mode (remember c:\>win.exe ??)
Also assuming that I will fully functional IDT which has translated every interrupt vector (total of 256) from IVT in real mode.
The only reason, I am going to pmode is to enough memory so that I can load as many exec.binary into memory as I wish, I actually contemplated using big-real mode but it is said big real mode can still not allow the CS to go above 64K so that will not work.
Is it possible that DPMI is all you need? Btw, there's a ring 0 version of CWSDPMI, which will run your code in ring 0, which might be handy for some tasks.
never dealt with virtual 8086 mode nor DPMI. Perhaps it is more straightforward to deal with video buffer directly. is that how kernels usually do? How about int 10h video services, would it be good idea to use it at all? if not, if not i am going to take a shot and try to do a video module. I think I am quite murky on these areas.