OSDev.org

Hello there,
I'm going to show you how to implement the cls command into your NASM assembly language kernel.
Level: Piece o' cake
Code:


If you are following one of OSDev's real mode assembly tutorials, you may use .
Hope this works.

WTF? I seriously doubt that any sane kernel in 2018 (even hobby ones) would use realmode as main operating mode... Besides what if I'm using 80x50 or 132x60 resolution? Or even better LFB? And what if the kernel is booted on a UEFI machine? And why do you use two mov instructions? Why not "mov ax, 3"?

And what's that jump to a arbitrary label??? There's simply no sense in that without a context.

Oh, look, BZT is back, under yet another account. Let's see how long that lasts. Kind of surprised the Mod Squad haven't noticed that yet after two months. Though come to think of it, I don't recall if that first account was permabanned or not. The user listings and profiles don't show if someone is banned as far as I can tell, so I have no idea of that account's status.

Admittedly, you may simply be someone else using a similar name, but it does seem a little suspicious, especially since there are about a dozen accounts with the form "bztx" already, most of which having either no posts or only one.

OK, now that the necessary cattiness is out of the way, I will say that I agree with what bztxyzomgbbq said, though I would have put it in a rather less confrontational manner (and yes, I am aware of the hypocrisy of saying this after that snipe I took above).

First off, I think most kernel developers would not consider this a kernel-level operation, even for a Monolithic Kernel with a Text UI. As a rule, you want to keep only a bare minimum of user interface primitives in the kernel itself, and whether that would include clearing the screen is debatable.

Second, as was already said, for most OS developers of the past 30 years real mode has been a dead end, something you are forced to start in during the boot sequence but which you want to get out of ASAP. Rumors of real mode's imminent demise have been around for a long time now, and while it hasn't happened yet, it is clear that every stakeholder in the situation - Intel, AMD, Microsoft, pretty much every single motherboard manufacturer out there, and especially Linus Torvalds and his merry band - have been looking to put a stake marked 'UEFI' through real mode's heart at the first opportunity they get.

Frankly, the only reason why real mode - and indeed, the x86 ISA in general - has persisted this long is because no one wants to have to clean up the mess that ditching it would cause. They've been creeping up on it, like Garrett getting ready to bop a guard while he's busy talking about going to the bear pits tomorrer, but the institutional will to get it over with has been lacking, and more's the pity since this should have been dead and buried before most of the people currently posting here were born. </rant>

Third, clearing the screen isn't the primary purpose of the INT 0x10, AH=0x00 BIOS service routine. What that routine actually does is change the video mode; clearing the screen is a side effect.

It can be used for that purpose, but it isn't a good approach. Since video mode setting using the BIOS is a pretty slow process, for text mode it is a lot faster to simply perform a bulk write to the current page in the text buffer. You would need to know the current page and the text mode being used beforehand, but frankly, if you don't know that already, you have bigger problems as an UI developer anyway.

Finally, the thing about the loop? OK, the intent seems pretty clear (that you would put the label 'mainloop:' - excellent naming convention, BTW - before the start of that code), but the fact that you are suggesting looping in the first place seems to indicate that you might not be as clear on what that code snippet would actually work.

As for the real mode tutorials, well, a) those were meant to teach assembly to newcomers, and so give practice examples to be performed before tackling OS dev, b) there is a long-standing disagreement over whether those pages should be there at all, since teaching assembly programming is out of scope for the wiki and while I personally have written introductory assembly pages, I put them in my own user pages rather than the main wiki for this very reason, and c) they were written in 2008, at a time when a lot of people had the mistaken impression that it was easier to learn real mode assembly first and then learn protected mode (which was sort of the case circa 1996, but really wasn't any more by the time those were added).

Hi @Schol-R-LEA, I'm glad you're happy that I'm back, but I haven't left. This is my no.1 site when I need something to laugh at >D

come on. you sound offended, I by the way don't quite understand what you had been banned for, I am not for banning everyone, except spammers and malusers with bad intentions, but I'm not a moderator either. but saying similar like you said bolded, is just ... infantile. tryna sound as an arrogant @$$ when it all screams about offense is childish.

UEFI isn't yet supported, you need mov ah, 0 (In other words, you can use mov ah, 0Eh). Note: I am experimenting with the code

Hi,



Please ignore the troll.

However, you should also understand that you're an enthusiastic beginner (which is great - that's mostly what this site is for - to help enthusiastic beginners learn) and because of this some things are new and interesting to you; but a lot of the people here are more experienced and for these people (the people you're saying "I'm going to show you how to implement the cls command" to) these same things haven't been new or interesting for a long time.


Cheers,

Brendan

I'm not sure what you are trying to say with this. Not supported by what? The statement makes no sense to me - it isn't a matter of 'supported' or 'not supported', for either the system firmware or the software. A system either has a UEFI firmware, or it doesn't.

OK, time for one of my infamous long-winded expositions. I don't know how much of this you already know, but please bear with me. Oh, and if anyone spots any errors, please let me know.

The Extensible Firmware Interface specification was introduced by Intel in 1997-ish, originally as the standard for Itanic, I mean Itanium, systems (also called IA-64). By 2000 or so, several other hardware vendors got on-board with the idea, and in 2005 Intel handed control of the spec to the Unified EFI Forum, which released the first UEFI spec by the end of that year. The spec was changed to work with several different CPU and peripheral types, not just x86 and IA-64, and most ARM systems now use UEFI. All Apple x86 systems have used UEFI from the start as well. It took about five years for it to really take hold in the PC world, however.

As a rule of thumb, any x86 motherboard made before 2005 is probably going to be Legacy BIOS and always boot into real mode, though a few EFI x86 motherboards were made by Intel between 2000 and 2005. Most of the PCs between 2006 and 2010 were Legacy BIOS. They increasingly moved to UEFI starting in 2008, but they didn't really surpass Legacy until 2010. Pretty much any PC motherboard made after early 2011 will have a UEFI firmware.

Most UEFI firmware systems have the optional 'Compatibility Support Module', which allow the system to boot in 'legacy mode' emulating the Legacy BIOS, but this is something that you would need to set in to UEFI setup before installing any operating systems. After around 2016, more and more have been shipping without CSM (which means they no longer have the BIOS routines in the firmware, period, and cannot run in real mode at all), and (according to the Wikipedia page) Intel announced last year that they will be dropping CSM entirely by 2020. My understanding is that all of the other UEFI implementers are at least considering following suit.

Now, to be fair, there are still plenty of Legacy BIOS systems out there; the laptop I currently use is one, dating from 2009. But the general pattern is that in any given year, there will be more systems less than five years old in regular use than there are which are over five years old. The majority of systems you will see today will be UEFI, even if they are set up to boot in CSM mode.

Support for UEFI on the kernel level is, well, as a rule it is simply irrelevant, unless the kernel is written to be entirely dependent on a specific boot loader and set of boot-up conditions. In a UEFI system, the kernel has to provide a shim file to the UEFI loader (at some location in a UEFI-readable file system, with the extension of the form '.efi') which tells it what state the system needs to be at load time (in particular, what operating mode it expects), and what information the kernel needs from the boot loader at hand-over.

If well-designed, this shim will act as a bridge between the firmware and the kernel, and the kernel won't need to know what sort of system it is at all (for the boot process, that is). Unless the kernel uses the runtime firmware services (whether in the legacy BIOS API or in the UEFI Runtime API), it doesn't even need to know what sort of system it is - and as a rule, OS developers have been using runtime firmware services as little as possible since the early 1990s.

My understanding is that the UEFI loader will only boot into either 32-bit protected mode, or 64-bit long mode, unless the entire system is set in the firmware configuration to start in CSM mode - in which case it must start in 16-bit real mode (and use a Master Boot Record instead of a GUID Partition Table), and leave anything involving the higher modes to the boot loader on the disk. I am not entirely sure of this, however, so I would love to hear from anyone who can confirm or dispel this.

TL;DR - your statement doesn't make sense to me. What did you mean by 'not supported'?



What bzt is saying is that the AL and AH registers are the two lower and upper halves of the AX register, so the two 8-bit move instructions



have the exact same effect as the single 16-bit move instruction:



while being slightly more compact and faster. I honestly don't see it as being a significant optimization either way, since the difference in size and speed are negligible. However, it sounds as if you may not have realized that they are the same, so bzt's comment was probably a good point.

Note that things would be slightly different if the value of AH were something else; for example, for



the replacement would be:



or, if you prefer the postfix base form,



(Note the use of hex; this isn't strictly necessary, but it simplifies things a great deal in this case, as the two bytes are represented in two hex digits apiece. If you really want to stick to decimal, it would be



Either way, it puts the same value into the register.)