Thread: Assembly and C++

  1. #1
    Registered User
    Join Date
    Dec 2004
    Posts
    6

    Assembly and C++

    So, I have written a basic operating system that loads up off a floppy, and starts a simple .com application (Written in Assembly as well). I want to write a shell now, but I am not sure if I should continue it in Assembly, or if i can do it in C++. If I can, how would I go about doing it? I know it would have to be command line style, but thats about it. Thanks in advance.

  2. #2
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Well have you written a c++ compiler that will work with your OS? If not then you pretty much have no choice but to do it in asm.

  3. #3
    Registered User
    Join Date
    Dec 2004
    Posts
    6
    Well, I can assemble the files beforehand, cant I?

  4. #4
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    What you could do is write the OS dependent implmentation and use a multitargeted compiler such as gcc.

  5. #5
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Try it and see?.. Though I know next to nothing about such matters, I don't imagine there should be any problems unless you're using features that are Windows-specific. Of course, that IS rather hard to distinguish, i.e. I imagine std::cout/cin are specific to the OS; pointers, linked lists, math operators etc. probably aren't. I'm working on the assumption that the same machine code instructions will do the same things on different OS's assuming the CPU instruction set is the same, and that the problems of compatibility arise from expecting certain conditions to exist in the running environment which will only be present on a specific OS. I suppose file I/O might be incompatible too, since different OS use different file systems.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  6. #6
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Pretty much everything that isn't a system call should work with the same instruction set. But things like I/O, memory allocation, executing another program (which a shell would do), etc are all system dependent.

    I would also look at the source for bash to see how they did it. Though I'd venture to guess they used C as its easier to keep it at a lower level then C++.

  7. #7
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    The next step for you is to load your kernel into memory and begin coding in C. The quicker you get to C the better and the faster the development time.

    Sounds like you have already coded the important parts that MUST be in assembly. However I'm confused about the COM bootstrap. Your boot strap should lie at sector 0 track 0 and be exactly 512 bytes in size. If you are loading a COM file for the interpreter code or command prompt then you would first load your kernel into memory and/or the interrupt handlers you need to install and then load your COM file into memory and far jump to the start of it.

    But for a shell or GUI you definitely want to move to C as fast as possible.

  8. #8
    Registered User
    Join Date
    Dec 2004
    Posts
    6
    Thanks for all your help. Also, Since I am writing my own kernel, is there any must haves that I should have in there? (Like important things it should do?)

    And, someone said my shell had to be under 64k because it was a .com application. How can i get around this?
    Last edited by LoafOfBread34; 12-12-2004 at 11:39 PM.

  9. #9
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Make it a flat binary in protected mode or in real mode set your selector limits to 2GB and load in the code via that selector. However setting the selector limits to 2GB and then popping back into real mode is quite an unstable environment to work in.

  10. #10
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    I'd stick with gcc and make your OS capable of running the ELF format. Or might I be so bold as to suggest, write code in C/C++ have your compiler output assembly. Generate the machine code for the exe using the assembler, then write a sepate program to write out the file header for your executable format. Here is the deal though, I'm going to safely assume you don't have something that even runs executables. You may want to get that running before doing anything. Afterall, as we all know a compiler isn't a mind reader when it knows what OS its generating code for, you are making it even harder on the compiler by not supplying it with sufficient knowledge of what to do with machine code it generates.

  11. #11
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > (Like important things it should do?)
    Lots of reading for one thing
    http://www.nondot.org/sabre/os/articles

    > And, someone said my shell had to be under 64k because it was a .com application
    Only if you intend to tie a noose around your neck and stick with a 16-bit world.

    Sure if your OS is "dumb" and has a very simple loader, then having executable files which are essentially a snapshot of memory is pretty easy.

    But investing time in making a more capable loader (one for say ELF) means you can have a much richer set of executable file options.

  12. #12
    Registered User PanzTec's Avatar
    Join Date
    Sep 2004
    Posts
    24
    hmmm... where can i learn to make my own OS??? I am ok at C++ but thats all i know
    The Matrix Will Live Again!

  13. #13
    Hardware Engineer
    Join Date
    Sep 2001
    Posts
    1,398

    Minix

    There is an operating system called MINIX. It was created to teach you how to write an operating system. MINUX is free, but you have to pay for the book. That's how Linus got started. It would probably be a good idea to look at the Linux code... but you might need a book to guide you through that too... 2.4 milllion lines of code in Linux 2.4 !!!! I'd suggest looking into the history of Linux too.
    Last edited by DougDbug; 12-14-2004 at 02:23 PM.

  14. #14
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Coding an OS is no small feat. It's not exactly hard, but there are about a million things you need to consider because your code runs the computer. As such you must monitor everything that goes on - including things we take for granted like disk access, memory management, thread priorities, interrupts or lack thereof, etc, etc. The list goes on for miles and miles. It is quite complex. Any number of events could happen at the same time that your OS must know how to deal with or at least have a mechanism for catching such things.

    For instance if one thread is writing to a file and your OS then switches to a task that is also writing to the same file....do you close the first file and/or handle and store the file pointer for it and then create a second handle to the file...or do you create a semaphore mechanism or a mutex mechanism that protects and/or shares files across multiple processes? Do you use shared memory between programs or do you use separate independent memory spaces.

    And then for memory management. There are a million ways to go about handling/managing/allocating/releasing memory. Are you going to use segmentation or are you only going to create a minimal number of selectors - those that are for the OS code,stack, and data and thost that are for all programs code, stack, data. If the latter is true then you also must create a system or structure that stores where in the big 'chunk' of memory each processes code, stack, and data reside as well as access limits and/or protection between those segments and other processes.

    I would suggest buying the book MMURTL from over at flashdaddee. The link to the book is in the OS-dev board in the first sticky post called OS dev resources.

    Incidentally if you do not know assembly now would be a good time to dive head first into the Intel x86 32-bit and/or 64-bit books. The 32-bit set has 4 volumes of books and the 64-bit has 3. You will need these close by your side as well as tons of white papers, tech papers, and docs for hardware, bioses, motherboards, chipsets, drives, etc., etc.

  15. #15
    Registered User
    Join Date
    Aug 2007
    Posts
    20
    Coding an OS is one of the most complex projects you can take on. There are numerous things that you have to implement (well ) before you can even get text on to the screen.

    An OS is a type of project where you code loads and get hardly anything back that is rewarding ( visually ).

    Once you have a strong kernel coded ( which in its self can take years! ), you can more on to the more rewarding stuff, like GUI development. Although this sounds fun, it can be as hard, or even harder than writing the kernel its self.

    Not to mention networking, API's, etc...

    I am certainly not trying to put you of though! I am currently working on my own OS project! I think it's great to know that your code is the only code running on the machine ( or inside VMware, which ever way you like to look at it! ). If you manage to get a OS up an running with a shell, and the ability to run a text editor ( like EDIT on DOS), then you have come an awful long way!

    Now this seems completely pointless, when you could just pop up eclipse and create a text editor in 30 minutes! But, that is not the point, coding an OS involves a range of topics, and you must know these well to be able to make an OS. This gives you an immense understanding of C/C++ (or whatever), Assembly, General Computer Science, Memory, etc... Just think how this will help your programming career!

    MMURLT is not a very helpful book at all. I have got it and although it explains some concepts well, it does not do what it says on the tin ( or back cover ). It does not teach you how to build an OS from scratch, it just tells you the theory behind it, and then dumps a load of code on your lap in the 2nd half. A great place to start is http://www.osdev.org . This has everything you could want to get started!

    I hope this helps!

    Harry.

Popular pages Recent additions subscribe to a feed