OSDev.org

Your premise, of a 1:1 correspondence is false. It assumes that all possible operations can be represented by only one opcode. That is not true.

Not all assemblers will necessarily produce exactly the same code from a given program. Indeed, one assembler may fail to assemble a program that another is happy with. This could not happen if there truely was a 1:1 correspondence between assembly code and machine code.

Hi Brendan,

You're a living database of knowledge which stuns just about everyone who encounters you here. You're also extraordinarily generous with your time in helping others, sharing your expertise with them at enormous cost (I have no doubt) to the development of your own OS. You ought to step back for a moment though ask yourself why you've just spent so much of your valuable time attempting to rubbish the code of someone you shouldn't (if you believed yourself) even regard as a serious programmer. What is it within you that drives you to launch into an attack of this kind every time you spot a chance to stick the knife in?

My code does the job asked of it, and there's lots of scope for improving it as you've realised: I particularly have to thank you for pointing out the direction flag issue as that may actually matter on some machines. This was never a competition entry - I cobbled it together in a couple of hours for fun when the temptation to meet the remit of this thread finally became too great. I built it to suit the way I program, but also to suit the way I used to program in the early days when I used a more reduced subset of the instruction set. I wanted to build something that I might have been able to build way back at the start and from which I could have done everything else in much the same way that I did the first time round. I think that's what it does.


Says who? It may not be normal, but running with the interrupts disabled is perfectly viable. I have never bothered to use the BIOS for reading the keyboard and couldn't be bothered looking up the way to do so for BwtSecOS either, but anyone who wants to use the BIOS to get keyboard input can simply enable the interrupts. [I've just wasted fifteen minutes trying to find out how you read key input via the BIOS in Ralf Brown's interrupt list and elsewhere without success - I have better things to do with my time than go on hunting for things I don't even need.]


I've got a 486 gathering dust which appeared to have its keyboard ports and some FDC ports damaged by relentless machine-gun polling. Everyone here initially suggested that it was impossible to do such damage, but then someone said it could happen if it had been upgraded from a 386. I checked and discovered that it was indeed an upgraded 386. (I rescued it when its owner was throwing it out because I was looking for a cheap, expendible machine to build my OS on, so to me it was just a 486.) Now, it may just have been chance, but there is no harm in playing it safe to avoid the risk of someone else damaging another ancient machine in the same way.


I made three errors in that reply, two by not looking up the code in question: one was a typing error (65535 was intended rather than 15535), another was forgetting that I then set CH to 1 before running the loop, and the third was not noticing the case where the second delay loop runs without the first delay loop having done so first, meaning that CL could be anything. Putting the second delay loop there is certainly overkill, but to play it safe again I thought it worth putting some kind of delay between reading the status and data ports. I couldn't care less what value is in CL when using CX as a count in this instance - all I wanted to do was create a little extra delay which is at worst completely harmless. I could have saved some space there instead, but there was no pressure to do so as I was filling in a fixed size hole below the load_or_save routine which I didn't want to move. These were decisions made on the fly and never looked back at - there wasn't the need or the time.


A missing tool is not a broken tool - if you want to build from BwtSecOS there are going to have a lot of missing tools, so far calls save a lot of trouble. I didn't do it to save me the trouble of calculating two jump distances - my indexing system can calculate them even for real mode. If I was to go on developing an OS from BwtSecOS, I would have soon wanted to be able to type in bytes digit by digit, so that would involve writing code that would do far calls to the keyboard reading routine. Anyone else using it might prefer to use the BIOS to get the input for them instead, and they are free to do just that, but I wrote it primarily for me, imagining how I might have grown my existing OS out of it.


It was written once, debugged, modified later to add LBA capability, worked first go, and I never found the time to to back to tinker with it - it is reasonably compact, easy for me to follow, and it works just fine: I have much better things to do with my time than craft to some unnecessary level of perfection every bit of code I write along the way.


I have a little tool designed for removing a block from a bicycle wheel. It is supposed to be used in conjunction with a huge wrench which I don't own. I could go to the trouble and expence of acquiring one so that I can use it once every other year, or maybe I could even have a go at manufacturing one myself, but I can get by without it: I simply walk out into the street and use the grating of a drain instead. What actually matters is getting the job done on the few occasions it needs doing.


It's compact, it isn't a mess and it works. What you're looking at is a routine which used to do just CHS and which had LBA capability added into it later on. I could have written completely separate code for an LBA version or I could have written a new version of the whole routine from scratch, but I stuck with using what was already there as a base because it already worked, just building the extra capability into it. That is how to maximise progress.

I never put this forward as an example of code for others to worship or copy - it's code that does the job sufficiently well that I don't care about "improving" it any more than I care about sanding down and putting French polish on the internal wooden frame of my sofa.


You could stick it in a floppy-disk sized partition at the top of a flash drive - if someone was to use BwtSecOS to build a program which they later wanted to demonstrate on real hardware without having to drag around a USB floppy disk drive with them, that can be done.


Well, not just compactness, but it was also designed to be easy to read in machine code form during debugging. In a case like this, once it's tested and works, there's simply no pressure to rework it to make it faster or more compact as the potential gains aren't worth spending any time on, unless you're building something for a competition.


What you've actually done is required the data to become bloated instead, and you've also neglected to modify SI to line up on the next group of data - that'll cost you four bytes just to do that. Your compaction efforts with your superior code amount to requiring an extra 15 bytes. I'm not clear as to where you want to mov the track no. to either without costing more than the two bytes required for a push and a pop.


Do you still not understand the point that if someone was to use BwtSecOS to build something more capable, they'd be starting out with no tools other than those in the bootsector?


You don't really think, half the time: again you're completely failing to imagine yourself trying to build on top of BwtSecOS where all your own fancy tools (and all of my fancy tools) are out of reach. The address of the byte under the cursor isn't even displayed yet at this primitive stage, so if someone wants to load/save something else from/to disk or needs to read the keyboard, they can do so very easily with far calls without having to count out distances. If they'd rather use the BIOS for keyboard input, they can simply enable the interrupts and use the BIOS.


BwtSecOS is just a proof of concept - a warning not to use it on <386 would suffice.

ECX has to be cleared to 0 in case the upper 16 bits aren't 0. When the LBA location of the VBR is added to the total being built in ECX, it's vital that the upper 16 bits are 0.


That's actually addressing the wrong point - you've just jumped back to something covered above where you ended up with bulkier code.


If you read what I said carefully, the bit that say's "you've saved processor time" means what it says - it was clearly awarding you a point.


You're right - I misunderstood the bit you wrote here:-


I didn't realise the two rotates you wanted are actually the same one.


Totally unimportant with this kind of code.


No, that isn't your conclusion - that was your starting point. You just want to tell me yet again that you think my programming system is rubbish. In reality, my way of programming works very well and it certainly suits my needs better than your tools would meet my needs. Your way of programming is to me a nightmare. My way of programming is to you a nightmare.




So, you now say "it's just a little challenge for fun", but you haven't exactly treated it as such, have you! As for my "joke" project, a new version will soon be available to look at, so you might want to save up some venom to spit then. Buy a large barrel and start collecting it now.

Hi,



It's sincere concern for others. If you saw a child about to urinate on an electric fence, or take up smoking crack as a hobby, or attempting to launch a fire cracker from their anus; then it would be both cruel and unethical if you don't at least warn them against such hazardous acts. Warning people against the use of machine code (for more than just a challenge/joke) is the same.

If BwtSecOS was designed specifically for fun/challenge then that would've been fine. However, it wasn't - BwtSecOS was derived from a serious project, and the same development techniques (and even some of the same code) are being used for that serious project. If I wanted to "stick the knife in", I'd encourage you to continue your bizarre/hazardous "machine code" ways (and laugh at you behind your back as you suffer the consequences of actions I failed to warn about).



Says everyone. The normal advice is "don't disable IRQs for longer than you have to". This only applies when something is in control of the machine (e.g. the BIOS, or an OS), and doesn't apply when something isn't in control of the machine yet (e.g. before firmware starts its drivers, or after an OS has discarded firmware and before the OS has setup its drivers). It does apply to BwtSecOS where the BIOS remains in control of the machine the entire time.

The main reason for this is that disabling IRQs for longer than you have to screws things up in ways that whatever is in control (BIOS) isn't designed to handle - it can mean lost timer IRQs, failure to turn off the floppy motor, problems handling keyboard/mouse properly, etc.

You've "partially usurped" control over part of the hardware (the keyboard, at least if it's not USB without PS/2 emulation), and this masks some of the problems that disabling IRQs cause; but because you've only "partially usurped" control it's likely there's still plenty of potential problems with other devices plus additional problems caused by the "partial usurping" itself. For example, if the user presses keys fast enough while your code is busy updating the screen then key presses are likely to be lost; and because the BIOS's keyboard IRQ handler is still active (when IRQs are briefly enabled) it's still reading from IO port 0x60 and putting keypresses (that you've already "stolen") into its keyboard buffer (e.g. I wouldn't be surprised if someone using this utility starts getting "keyboard buffer full" beeps from the BIOS after a short while).

I don't understand how someone could look into "int 0x16" for 15 minutes and still not understand how to use the "get keypress" BIOS function.



Sigh. Do you understand that some CPUs will optimise "0xE2, 0xFE loop $" so that it takes no time at all (effectively doing "mov cx,0" instead, regardless of what CX contained beforehand)? How is a broken "0 cycles" delay supposed to prevent this damage?



No. Telling you that your programming system is rubbish isn't my objective. Convincing you that your programming system is "rubbish" (has severe shortcomings) is my main goal. Warning others not to follow your footsteps is an (almost entirely unnecessary) secondary goal. It's sincere concern for others. In the same way, I would attempt to convince you (or anyone else) that urinating on an electric fence is a bad idea.


Cheers,

Brendan

Brendan, it may not be a good idea to write directly in machine code, but I bet you that DavidCooper knows quite a bit more than the inner workings of a computer than you as a result.

I'll take that bet - after all I saw proof of the opposite earlier this thread ... *adds a few more invisible tokens to his account*

Worst of it all, this thread is derailed by a ton of assumptions of people that seem to lack certain basics in computer science to tell the difference between showoff acts and actual knowledge. What would you prefer: visiting a flashbang wizard that sells the same rabbit out of his top hat every day, or a professional breeder that can get you a fresh rabbit ragout to eat every day? You won't find the latter wearing fancy robes.