|Jump from isr to a program?
|Page 1 of 1|
|Author:||0x666c [ Tue Dec 25, 2018 10:56 am ]|
|Post subject:||Jump from isr to a program?|
Hello! I'm new here, so please pardon me if this is basic knowledge
Recently I was trying to implement some kind of program hardcoded in the kernel (very basic settings app).
Then, I didn't have a scheduler so I wrote something like that, specific for this app
A begin_program() function is called inside keyboard interrupt
Inside begin_program(), "scheduler's" program_entered() is called
program_entered() saves current register values, keyboard isr pointer, screen etc. Then it replaces the previous handler with one provided by the program
Control is returned to begin_program() after which initializing code is executed (currently it's only cls and printing "test")
begin_program() enters an infinite loop which checks if the user had pressed ESC or not, and from now on it relies only on interrupts
leave_program() function, which reversed begin_program()'s actions is called
begin_program() returns control to whatever interrupt called it
The whole thing doesn't work because interrupt which launched the program is never terminated. Basically, I'm asking how to launch some kind of code from inside an interrupt, which would be able to execute interrupts itself. Thanks in advance!
Tell me if you need my code or a more detailed explanation
|Author:||carver [ Wed Dec 26, 2018 1:48 am ]|
|Post subject:||Re: Jump from isr to a program?|
"It don't work" isn't very helpful, what issue are you having with it? Also, you will be better off in the long run writing a scheduler.
|Author:||Schol-R-LEA [ Wed Dec 26, 2018 11:07 am ]|
|Post subject:||Re: Jump from isr to a program?|
0x666c: Since you are a new member here, permit me to welcome you with these links and pieces of advice. I have been posting this for new members as a way of getting everyone started on the same footing. I hope it helps.
EDIT: thanks to Erjus for recommending some additions to my 'boilerplate' post.
The first thing I want to say is this: if you aren't already using version control for all software projects you are working on, drop everything and start to do that now. Set up a VCS such as Git, Subversion, Mercurial, Bazaar, or what have you - which you use is less important than the fact that you need to use it. Similarly, setting up your repos on an offsite host such as Gitlab, Github, Sourceforge, CloudForge, or BitBucket should be the very first thing you do whenever you start a new project, no matter how large or small it is.
If nothing else, it makes it easy to share your code with us on the forum, as you can just post what you think will be the relevant part and give a link to the rest, rather than pasting oodles and oodles of code into a post.
Once you have that out of the way (if you didn't already), you can start to consider the OS specific issues.
If you haven't already, I would strongly advise you to read the introductory material in the wiki:
After this, go through the material on the practical aspects of
running an OS-dev project:
I strongly suggest that you read through these pages in detail, along with the appropriate ones to follow, before doing any actual development. These pages should ensure that you have at least the basic groundwork for learning about OS dev covered.
This brings you to your first big decision: which platform, or platforms, to target. Commonly options include:
You then need to decide which Language to use for the kernel. For most OS-Developers this means knowing and using C; while other languages can be used, it is important to know how to read C code, even if you don't use C, as most OS examples are written in it. You will also need to know at least some assembly language for the target platform, as there are always parts of the kernel and the device drivers which cannot be done in high-level languages.
You further need to choose the compiler, assembler, linker, build tool, and support utilities to use - what is called the 'toolchain' for your OS. For most platforms, there aren't many to choose from, and the obvious choice would be GCC and the Binutils toolchain due to their ubiquity. However, on the Intel x86 platform, it isn't as simple, as there are several other toolchains which are in widespread use for it, the most notable being the Microsoft one - a very familiar one to Windows programmers, but one which presents problems in OSDev. The biggest issue with Visual Studio, and with proprietary toolchains in general, is that using it rules out the possibility of your OS being "self-hosting" - that is to say, being able to develop your OS in the OS itself, something most OSdevs do want to eventually be able to do. The fact that Porting GCC to your OS is feasible, whereas porting proprietary x86 toolchains isn't, is a big factor in the use Binutils and GCC, as it their deep connection to Linux and other Unix derivatives.
For most platforms, there aren't many to choose from, and the obvious choice would be GCC and the Binutils toolchain due to their ubiquity. However, on the Intel x86 platform, it isn't as simple, as there are several other toolchains which are in widespread use for it, the most notable being the Microsoft one - a very familiar one to Windows programmers, but one which presents problems in OSDev. The biggest issue with Visual Studio, and with proprietary toolchains in general, is that using it rules out the possibility of your OS being "self-hosting" - that is to say, being able to develop your OS in the OS itself, something most OSdevs do want to eventually be able to do. The fact that Porting GCC to your OS is feasible, whereas porting proprietary x86 toolchains isn't, is a big factor in the use Binutils and GCC, as it their deep connection to Linux and other Unix derivatives.
Regardless of the high-level language you use for OS dev (if any), you will still need to use assembly language, which means choosing an assembler. If you are using Binutils and GCC, the obvious choice would be GAS, but for x86 especially, there are other assemblers which many OSdevs prefer, such as Netwide Assembler (NASM) and Flat Assembler (FASM).
The important thing here is that assembly language syntax varies more among the x86 assemblers than it does for most other platforms, with the biggest difference being that between the Intel syntax used in the majority of x86 assemblers, and the AT&T syntax used in GAS. You can see an overview of the differences on the somewhat misnamed wiki page Opcode syntax. While it is possible to coax GAS to use the Intel syntax using the .intel_syntax noprefix directive, the opposite is generally not true for Intel-based assemblers such as NASM, and even with that directive, GAS is still quite different from other x86 assemblers in other regards.
It is still important to understand that the various Intel syntax assemblers - NASM, FASM, and YASM among others - have differences in how they handle indexing, in the directives they use, and in their support for features such as macros and defining data structures. While most of these follow the general syntax of Microsoft Assembler (MASM), they all diverge from it in various ways.
An important aspect in preparing your toolchain - regardless of which you use - is setting up a cross-compiler. The wiki page on creating a GCC Cross-Compiler has invaluable information even for those who mean to use a different toolchain, as it explains both the reasons you need to set one up, and gives details which apply to any cross-compiler, not just one using GCC.
Once you know which platform you are targeting, and the toolchain you want to use, you need to understand them. You should read up on the core technologies for the platform. Assuming that you are targeting the PC architecture, this would include:
This leads to the next big decision: which Bootloader to use. There are a number of different standard bootloaders for x86, with the most prominent being GRUB. We strong recommend against Rolling Your Own Bootloader, but it is an option as well.
You need to consider what kind of File System to use. Common ones used when starting out in OS dev include:
We generally don't recommend designing your own, but as with boot loaders, it is a possibility as well.
While this is a lot of reading, it simply reflects the due diligence that any OS-devver needs to go through in order to get anywhere. OS development, even as a simple project, is not amenable to the Stack Overflow cut-and-paste model of software development; you really need to understand a fair amount of the concepts and principles before writing any code, and the examples given in tutorials and forum posts generally are exactly that. Copying an existing code snippet without at least a basic idea of what it is doing simply won't do. While learning itself is an iterative process - you learn one thing, try it out, see what worked and what didn't, read some more, etc. - in this case a basic foundation is needed at the start. Without a solid understanding of at least some of the core ideas before starting, you simply can't get very far in OS dev.
Hopefully, this won't scare you off; it isn't nearly as bad as it sounds. It just takes a lot of patience and a bit of effort, a little at a time.
|Author:||Octocontrabass [ Thu Dec 27, 2018 12:55 pm ]|
|Post subject:||Re: Jump from isr to a program?|
The whole thing doesn't work because interrupt which launched the program is never terminated.
A typical implementation has two separate calls to the scheduler: one to tell it to add a program to the list of running programs, and another to tell it that it's safe to switch to another program if one is ready to run. The first function returns quickly, so you can call it at any time. The second function can run "forever" so you can only call it at the very end of the interrupt handler, after you've finished acknowledging the hardware.
Switching between programs is often done by switching between kernel stacks. Since the stack holds the return address, when you switch stacks you're changing where you'll return to. This allows you to pause one program indefinitely while another is running. Since you're switching programs in an interrupt handler, you need to make sure the interrupt handler is done with all of its work before it switches programs so it can be called again on the new program's kernel stack before it returns on the old program's kernel stack.
|Page 1 of 1||All times are UTC - 6 hours|
|Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group