OSDev.org

Combuster wrote:a prefix used in AMD's new 256-bit vector instructions

Intel's. AMD invented XOP instead.

Stanislav

Be advised then, AMD uses VEX as the official term for the 3-byte prefix, that happens to start with the XOP byte. (AMD software developer manuals, 256-bit instrucitons, chapter 1.1)

Edit: and as wikipedia suggests, VEX refers to the encoding scheme and not the implementation - 8F/C4/C5 are all possible first bytes for VEX prefixes, only used in different implementations.

bewing, you just left IRC when I wanted to ping you about it, so let me report the bug here...

I noticed that the cursor keys don't work when I tried to edit the boot configuration in GRUB. The problem is that you cast an SDL keycode to a 8 bit type. In fact however, key codes are not limited to 0-255, and the cursor keys start at 273. This means that you even overflow sdl2rbx when you build the keymap during initialization. This should probably be fixed.

According to the wiki, Bochs fills memory with zeroes until it's overwritten. Though useful, it would be handy if this could be disabled. The reason for this is that hopefully it would speed up booting a bit (don't have to clear big amounts of memory) and it would be handy to test whether e.g. code has been making assumptions about memory or one forgot to clear a paging structure before use.

Creature wrote:According to the wiki, Bochs fills memory with zeroes until it's overwritten. Though useful, it would be handy if this could be disabled. The reason for this is that hopefully it would speed up booting a bit (don't have to clear big amounts of memory) and it would be handy to test whether e.g. code has been making assumptions about memory or one forgot to clear a paging structure before use.

I agree it would be useful for the latter - some random garbage would be way better. As for the first, I would hope that Bochs is smart enough to not claim and clear all memory at once, and do a "clear on access" strategy or the like. Also, clearing memory is relatively low cost, compared to say the time it takes to emulate harddrives (or even floppies!).


JAL

Kwolf -- thanks for the tip. I'll fix that.

Creature -- Yes, rebochs already has this feature basically implemented. It's part of Nasty mode, for the bios. In benign mode, memory is zeroed. In nasty mode, if you enable it, all of memory is trashed with random garbage -- for precisely that reason.

jal -- initting memory at access time would be very slow, and I'm pretty sure that bochs does not
do that. I think it's zeroed from one end to the other. Thanks for the reminder, though -- I believe I will implement what you say in rebochs, as an option. But there is a reason why you shouldn't allocate more RAM for your OS testing than you need.

bewing wrote:jal -- initting memory at access time would be very slow, and I'm pretty sure that bochs does not
do that.

Well, if you are in PM, Bochs must check, on every memory access, whether that's paged in, whether the priviliges are ok, etc., so I wouldn't think that clearing memory (or at least a check for it) would be that big an overhead (on page level)?


JAL

And you should know that optimising means keeping code out of the critical path.

Seriously, in modern systems pumping out a gigabyte of zeros to RAM can already take less than a second. And then try loading grub from a floppy where every seek costs about as much.

Bewing, out of curiosity, have you considered implementing TLB entries in Rebochs?

It would be another feature for nasty mode (Though should probably be implemented in normal mode also)

jal -- yes, it's true that there are checks. I'd have to add a label to my linear_to_physical routine, so that all physical addresses could be checked at the end of the routine. Then have a (potentially)great big bitmap to check off, perheps several megs at a time -- because theoretically, memory can be many Gb in size, and it's not fixed, so I need to keep the bitmap size manageable. So it adds a dynamically allocated bitmap, some gotos, code to choose a byte out of the bitmap, and code to test the bit in the byte -- and all this code should probably be conditional, because I think I'd want it as a compile-time option (for speed efficiency).

Of course, there is more than one kind of efficiency. Delaying/avoiding the zeroing (or accessing) of sim memory allows the OS to delay actually allocating virtual pages to the sim -- which can be a huge savings if the sim is trying to allocate something really big -- which is likely.

Owen -- yes, the TLB is one of the pieces of "hardware" that I will be modeling when I get to it. It will have a "disable" line in the INI file when I have it implemented -- so that people can see how/where stale TLB entries make their code work differently.

bewing wrote:Owen -- yes, the TLB is one of the pieces of "hardware" that I will be modeling when I get to it. It will have a "disable" line in the INI file when I have it implemented -- so that people can see how/where stale TLB entries make their code work differently.

I'd have it always check the page tables, and if they're wrong, scream at the user: "Virtual address mapping for 0xABCDEF12 is stale (Page table: X, TLB: Y)"

Hmmm! Interesting thought! I'll contemplate that.

I checked out from the svn and tried to build with msvc 2010, and eventuall get this: What does it supposed to mean?

The next line is even funnier:A wide or word version of an 8 bits unsigned type that is initialized with wide strings?

-1 for Hungarian Notation. Perhaps he meant "word" to actually mean a "word" (as in "string")...