Only portion of screen working in VESA

[Combuster]

The magic search keyword is "calling convention".

And actually, this is a variation on a question from my ancient required knowledge exam...

[Schol-R-LEA]

OK, I looked over the test, and got a 10%, so that's embarrassing. I did a thorough walk-through afterwards, and could get the answers expected for all but the format string question eventually.

OTOH, I'm not sure if I understand the reasoning in questions 3, 5, 6, and 9:

3 - Heapsort? For an embedded system? Seriously? Setting aside the fact that we aren't really given enough information to draw a meaningful conclusion at all, I would think that you would want to avoid doing a lot of memory allocation and freeing operations, and while it is possible to avoid that by pre-allocating the nodes, the algorithm also has a larger memory footprint than any of the others listed. TBH, without knowing more about the specifics (the size of the expected datasets, the memory and speed of the system, the expected dynamic layouts of the datasets) I would probably choose gnome sort (or, if stuck with one that's on the list, bubble sort - yeah, I went there) despite it's weak performance with large datasets, because it has a tiny algorithmic footprint and the datasets in a real-time system are usually small enough that algorithmic efficiency concerns gets lost in the underflow - the code may well be larger than the data it operates on. What am I missing?


EDIT: OK, I see where I misunderstood now; the "add esp, 12" is the cleanup after the function return. I'm keeping the original comment below for reference, however.

5 - aside from the fact that it assumes a specific C calling convention - there are several - the answer given is wrong. it either should be only the argument pushes followed by the call - on the basis that you are showing the caller's side but not the callee's - or else should be

Code: Select all

push ecx
push ebx
push eax
call foo

foo:
push ebp
mov ebp, esp
add esp, <the total size of the locals the function uses>

Since there is no way of telling from the question how many locals are used, the question should be limited to the caller's side, right?[/i]

6 - While the operation is on memory in the stack, that doesn't mean that the stack segment register suddenly replaces the data segment register as the default segment accessor for that one operation, at least not to the best of my knowledge. The whole reason why almost everyone uses a flat memory model in protected mode (aside from just the sheer cussedness of dealing with segments) is because it sets DS and SS to the same segment base, allowing these operations to work without an explicit segment modifier - the memory access is still through DS, it just happens to be the same as if it were through SS. Or am I misunderstanding this?

9 - While I can see why 2 and 3 are wrong (the lack of #include'ing <stdio.h> and the 'void main()', respectively), why is line 5 wrong? The only thing I can think is that the file is getting terminated incorrectly (i.e., there ought to be a newline after the close brace and an empty line 6), but that has to do with the compiler rather than the program itself, and while the fact that GCC warns of a possibly truncated file is a Good Thing (or at least was back when random line disconnections were a common occurrence), it isn't actually a C Thing.

I await your explanations of why you were right and I am wrong; I am actually hoping I am wrong, because learning is usually a good thing.

[azblue]

6 - While the operation is on memory in the stack, that doesn't mean that the stack segment register suddenly replaces the data segment register as the default segment accessor for that one operation...

Yes it does.

The whole reason why almost everyone uses a flat memory model in protected mode (aside from just the sheer cussedness of dealing with segments) is because it sets DS and SS to the same segment base,

Yes...

allowing these operations to work without an explicit segment modifier

Yes...

- the memory access is still through DS, it just happens to be the same as if it were through SS. Or am I misunderstanding this?

Nope. It's the other way around. The memory is accessed through SS, and it just happens to work the same as if it were DS.
You're right that in flat mode it doesn't really matter, but the access is technically through SS.

[Schol-R-LEA]

Ah, I did not know this. Thank you.

And now I can't decide if that was brilliant of Intel's engineers, or utterly pants-on-head. How does this work? Do all indirect accesses with EBP orESP as their base address use SS as the default segment base, then?

[alexfru]

Do all indirect accesses with EBP or ESP as their base address use SS as the default segment base, then?

Correct.

[Schol-R-LEA]

Ah, OK, that does make sense I suppose, it's a special case but not an unreasonable one given that the registers in question are not general-purpose registers.

Still, for someone who learned computer architecture from a more RISCy perspective, that's really just more reason to see the x86 architecture a as a rickety pile of hacks. Seriously, they did know better ways to design a CPU than this in 1978, the Motorola 68K (a CISC design almost as ginormous as the VAX, but a great one) proves it, but their insistence on half-baked source compatibility with the 8080 is still causing us grief after almost forty years.

[alexfru]

Ah, OK, that does make sense I suppose, it's a special case but not an unreasonable one given that the registers in question are not general-purpose registers.

Still, for someone who learned computer architecture from a more RISCy perspective, that's really just more reason to see the x86 architecture a as a rickety pile of hacks. Seriously, they did know better ways to design a CPU than this in 1978, the Motorola 68K (a CISC design almost as ginormous as the VAX, but a great one) proves it, but their insistence on half-baked source compatibility with the 8080 is still causing us grief after almost forty years.

x86 isn't that much of a problem as it was in its infant years. You rarely get to write assembly code these days. But if you must, it's usually 32-bit or 64-bit code, where you don't need to be concerned about segmentation or about things being very irregular and restricted (like a very restricted set of memory operands). And it's much easier to debug and try things out, no need to reboot the system on every mistake. It's only our OS-dev-like projects, where we have to start nearly from the scratch and ignore a lot of progress that has been made in the past several decades. But if it's a hobby, one could pick a different, simpler and/or more regular architecture to play with. MIPS is pretty good in terms of being regular and easy on the learner. There are emulators and cheap boards with MIPS CPUs.

[Schol-R-LEA]

Fair enough. TBH, the only reason (aside form cash flow issues) I haven't switch to either MIPS (which I know quite well) or ARM (for which SBC hardware is abundant) is because I am aiming at portability, and I figured that when writing my assembler it might be better to tackle the harder architecture first than to write something that works fine for, say, a Raspberry Pi 2 or a Creator CI20, but proves to be a poor design fit for the Intel CPUs. I am keeping an eye on the other architectures while writing Assiah (the assembler), and will do the same when (well, if) I get around to working on Kelephstis (the hypervisor), and Kether/Da'at/Coronet (the operating systems, for desktop, server, and mobile, respectively), and in particular I'm trying to keep the mnemonic mapping DSL as generic as possible.

[embryo2]

Assiah (the assembler), Kelephstis (the hypervisor), and Kether/Da'at/Coronet (the operating systems, for desktop, server, and mobile, respectively)

Nice naming. Tell us the history behind it, please.

[Schol-R-LEA]

Assiah (the assembler), Kelephstis (the hypervisor), and Kether/Da'at/Coronet (the operating systems, for desktop, server, and mobile, respectively)

Nice naming. Tell us the history behind it, please.

Well, it actually started as a sort of joke; I knew some Thelemites (members of the OTO and other groups associated with Crowley's words and works, as well as less directly affiliated Chaos magickians), and, being a Discordian myself (which means I have more than a bit of To Mega Therion's influence in my Belief System, too), I chose the name Thelema for my language partly to poke fun at them, and partly because I wanted to design it in a way that doesn't get in the way of the programmer - that is was in accord to the programmer's True Will, if you like. I even made a slogan riffing off of Rabelais' Code of Thelema: "'Do What The Programmer Wilt' Shall be the Goal of The Code."

When I decided to split the overarching toolchain and operating system into different projects, I started with 'assiah', the Qabalistic term (or one of them at any rate) for the material world. The ELF support used to work with them in Linux became Alfheim, the bootloader would be Bereishith (the Hebrew word usually translated as 'In the Beginning'), the hypervisor Kelephstis (Attic Greek for 'coxswain'), and the operating system would become 'Kether' (also spelled 'keter'), the Hebrew word for 'crown' and the highest point in the Qabalistic Tree of Life. Da'at is a more esoteric name for the same thing, while Coronet is simply because it is a small crown.

Source code elements such as functions, type definitions, macros, etc became 'sacra' and the portable AST documents became 'relics' so the repositories became reliquaries.

Of course naming things is the easy part; actually getting them written is another matter entirely. There is a reason bikeshedding is an anti-pattern.

[embryo2]

Well, it actually started as a sort of joke

Nice joke, a lot of ancient words with many corresponding associations (for those with a bit of history knowledge).

Source code elements such as functions, type definitions, macros, etc became 'sacra' and the portable AST documents became 'relics' so the repositories became reliquaries.

But it all is too religious. However, religious people tend to polish their vocabulary at a highest possible level (a kind of best loved poetry?).

Of course naming things is the easy part; actually getting them written is another matter entirely. There is a reason bikeshedding is an anti-pattern.

Bikeshedding is a kind of psychiatric disease? A new and even insightful vision

I suppose the next appropriate road is about OS development taxonomy - from religious naming with intricate interrelations towards system entities with strictly defined relationships. What about the USB interconnect magic? Or cryptic ACPI's AML world exploration? Neither goes for you? Then take (with the help of your skilled imagination) a Wi-Fi rock or GPU mountain or something more esoteric like Bluetooth stack

[Schol-R-LEA]

Source code elements such as functions, type definitions, macros, etc became 'sacra' and the portable AST documents became 'relics' so the repositories became reliquaries.

But it all is too religious. However, religious people tend to polish their vocabulary at a highest possible level (a kind of best loved poetry?).

Heh, that's a very good point, to be certain. However, I am being tongue in cheek here - I am, as I say, a Discordian, which means taking religion seriously is against my religion - so it still shouldn't be too big a problem.

Of course naming things is the easy part; actually getting them written is another matter entirely. There is a reason bikeshedding is an anti-pattern.

Bikeshedding is a kind of psychiatric disease? A new and even insightful vision

More of a symptom, really - Parkinson's original point was that if a person or group of people is assigned to work on a task that they have no domain knowledge for, they will usually put all of their effort into the part that is most familiar to them, as a coping method for dealing with the frustration of being out of their depth, rather than admit that they have no idea what to do.

Or were you talking about religion still? While I certain would agree that every BS (that's Belief System, by the way, not that other less forum-friendly term) involves at least some amount of delusion, I would hardly limit that insight to theology. The real problem lies in the limits of the human neuroanatomy and neurophysiology, so we're kind of stuck with people who believe in obvious nonsense that is different from the obvious nonsense you believe in. What the Cheshire Cat said about going amongst mad people doesn't just apply to Wonderland fnord.

[embryo2]

Parkinson's original point was that if a person or group of people is assigned to work on a task that they have no domain knowledge for, they will usually put all of their effort into the part that is most familiar to them, as a coping method for dealing with the frustration of being out of their depth, rather than admit that they have no idea what to do.

You have no wife, no children and going to meet half a century of life soon. You can try the idea of socialization, but may be it's too late.

[Schol-R-LEA]

I think you meant to post this in the other thread, as my psychological problems have no bearing on this.

I gather you are unfamiliar with the term 'bikeshedding', which just means 'spending time debating side issues instead of working on the assigned task'. It was coined in reference to the "Law of Triviality" from the book Parkinson's Law (a collection of essays on business management), and refers to a hypothetical scenario where several non-engineers are planning the layout of a nuclear power plant, but spent meeting after meeting arguing over what color a bike shed at the plant ought to be painted; the author, an economist and management consultant, argues that this sort of thing occurs because the people involved would rather focus on things they can contribute on, and where opinion has as much weight as facts, or more.

(He originally presented this as a corollary to the eponymous Parkinson's Law, a humorous take on Jevons' Paradox regarding time management that states, "Projects expand to fill the time available for them". A more general formulation I often use is, "in the absence of other limitations, use of non-limiting resources increases until one or more of them becomes limiting", which I originally thought up in regards to population ecology - e.g., if there are no predators in a given habitat, a prey population will rise until the food supply, water supply, territorial space, or something similar becomes a limiting factor - but applies to pretty much anything.)

Since bikeshedding is a common problem in project management, it is considered a management anti-pattern by most people who are into the whole 'design patterns' thing.

As for a family, I would sooner see the world burn than inflict my catastrophic genes on another generation, and I would prefer to be the. .. no, I'm saying too much for this forum again. Ignore that part.