I think 8086 should be much faster than 8088, since it has 16 bit data bus it can fetch 16 bit data at a time, when compared to 8088 which can fetch only 8 bit data from the memory
Define "much" ;-> In reality, its something in the range of 30% faster on average. The prefetch queue goes a long way towards flattening the performance between the two.
In the specific case of a far jump, actual results can vary dramatically depending on the states of the prefetch queues. If both CPU's have the opcode and address in their queues, they'll both execute it at the same speed (fetching the NEXT instruction at the target address is a different story as the jump blows away the prefetch queue contents). If a costly instruction was before the jump allowing the prefetcher a lot of time to load the queue, they'll both execute the jump at the same speed -- their execution units are identical.
Use DL rather than DX. The group of functions you have to be calling (you didn't say which of several possibilities you're specifying in AH) don't use DH. A MOV to DX is 3 bytes, a MOV to DL is two.
Could use '$' terminated string output API too (Int 21h fn 09h)
Almost everything executes faster on the 8086. It has a 16 bit bus rather than the 8088's 8 bit bus.
The execution units on the two chips are identical. The only difference is bus width and depth of prefetch queue. The 8088 has a slightly deeper prefetch queue to try and compensate some for the constrained bus bandwidth.
If you use a mutant form of AAM or AAD (I forget which right now) that uses 16 as its base rather than 10, it will cleanly split the nibbles in AL into AH and AL.
Also, what's the difference between programmnig for AMD vs Intel and the different chips within these companies.
No difference, other than errata unless you start wanting to exploit things like 3DNow or MMX/SSE stuff. Stay with the common 8086/286/386/486/Pentium subset and they're all pretty much the same.
And if you could, it doesn't look like they wouldn't be useful on AMD, correct?
For the common subset of user space instructions, the Intel Manuals will be OK. There will be some processor specific stuff you'd need to use in the guts of an OS, but you're not to that stage yet.
Dear friends i am in need of assembly code for interfacing RTC with 8051 microcontroller. plz help me as soon as possible:-|
It might be more useful to have a hardware design that will work first...since there's probably dozens of different RTC chips and dozens of 8051 variants, and hundreds of different ways one might lash them together.
why no one writes anything but trivial programs in assembly language.
I assure you the OS/2 kernel, KBD, MOU, VIO, and base drivers code was non-trivial. It was all done in assembler.
In the 1.X and GA 2.0 version the PM graphics engine was assembler as well. The VGA and 8514 drivers was all assembler and large chunks of the XGA driver were assembler.
Gibson claims everything he does is assembler. don't know if that's true or not, but its what he claims.
I've got a 100,000 LOC test suite for the DOS Int 21 API that's done all in assembler.
a whole os in assembly. its got a GUI and is under 5 meg
OS/2 1.3 would run on a machine with well under 3M of memory, and the whole system shipped on about 8 or 9 1.44M diskettes (including display/printer drivers).
Anybody who writes a memory resident debugger, which can randomly interrupt the execution of a program at any point, will soon discover that the average app spends about 90% of its time executing operating system code. Therefore it can be as fast as the OS, and no faster.
Its a very bold (and 100% wrong) assumption that all computer systems have an OS or one that they're CPU bound upon.
You seem to be a very GUI/desktop centric person. I assure you, there's a whole world out there you've never seen.
You seem to hold the guts of an OS as some sort of impenetrable black box who's will we a simply subject to. Having spect a significant portion of my career in the guts of OS's and drivers, I can state this is not the case, and the cure for performance issues in OS's is often assembler code. In fact the guts of the OS/2 kernel were virtually all assembler with few exceptions (HPFS was mostly C). Run OS/2 on anything and compare it to Windows or Linux in terms of speed and responsivness. There is no comparason. All that assembler code beats the crap out of the C code systems.
True, it can be used to develop any kind of application, but what would be the point when a high or middle level language can do the job just as well (and more quickly)?
More quickly? Perhaps.
As well? No. I can beat any compiler on speed or space optimizations. One of the biggest problems with compilers is they must implement the semantics of the language. Those semantics never map optimally to any particular architecture.
ex. on x86 I've never seen a compiler pass a bool flag to a function using the carry flag. They all waste time pushing a stack var, or blow a register.
None of them know how to do extreme space optimizations.
The Space Shuttle's cockpit displays/keypad processors (an IBM SP0) were programmed in assembler as was its Heads Up Display(HUD) symbology processor (Hughs A10INS processor)
All of the kernel (and the vast majority of stock drivers and TSR's) for plain old DOS were written in assembler too.
We had assemblers though. The SP0 wasn't all that obscure (in aerospace circles that is). Shuttle uses it, and the Navy's Harpoon missile is using them somewhere.
The DOS loader stuff isn't very obscure. Millions of copies of DOS 5 and later shipped.
Sometimes you simply can't get a commercial tool to produce what you need either. There's some hand assembled stuff in the guts of OS/2 because we couldn't get a compiler or assembler to spit out what was needed.
Patches are frequently applied in machine code. NASA's procurement process for Space Shuttle flight software had the vendor providing a "signed off" image. Subsequent fixes after image sign off were applied as machine code patches. I had 20 words of patch space to work with in the Shuttle's SP0 cockpit display processor. Split 8 here and 12 over there. A reassemply/recertification of the load image to collect them up together was too economically painful to think about. We did hex patches.
Obviously debuggers and such need to do it when they implement the ability to alter code on the fly, and OS internals often do a bit of it when applying patches to known broken apps before allowing them to execute. DOS 5 and later for example, patch the in memory image of applications built with a buggy version of the Rational Systems DOS extender before giving them control.
Do you mean tha I have to convert from bcd to real and from real to bcd?
Every floating point printing routine I've ever worked with for x86 scales the exponent and uses the NPX(or emulator) BCD to convert the 64 bit fraction for printing.
I think you need to take a look at the IEEE 754 numeric standard. Then all of this will make a lot more sense. The Intel programmer ref for 486 includes the NPX supplement, its a seperate doc for 387. The 286 programmers ref has the 287 supplement included, and the 8086 docs did it as a seperate doc.
If you want to do this without hardware BCD(or x87 emulator) you've got a challenge.
Whatever that big blog of stuff is, it isn't going to make printable floating point values. I didn't see anything in there doing BCD which almost any reasonable number display routine will have to do.
C language, for example, is portable as long as (1) the programmer sticks to ansii C standard functions and (2) there is a c compiler targeted for the platform.
C has issues a programmer needs to keep in mind if they want truly portable code that go well beyong the RTL.
The standard is full of the weasle words "implementation defined" and "behavior is undefined".
One of the biggest issues is non-crisp semantics for data types. That was something ADA took on directly and actually resolved in its spec. ADA semantics are dictated 100%. C punts quite often - you don't even know if a 'char' is going to be signed or unsigned by default in any given C implementation.
People who write genuinely portable code for a living get around most this with lots of synthetic types, extensive use of limits.h, sizeof() and a keen eye to where some snip of bit banging code might not be word endian neutral or word size neutral. The vast majority of C programmers in the world don't exhibit that kind of dicipline though.
The actual hardware RTC lives in the clock chip. Maybe you'd better think about how to retreive stuff out of that before worrying about diaplaying it on the screen. First things first.
What they want you to do is take the CPU's pipeline into consideration when writing the code. On the newer x86 CPU (486 onward) you can get significant speed boosts by ordering stuff so stages of the pipeline don't stall wiating for other stage results.
The load of DI and its use in the next instruction are in close proximity and can cause a stall. The code will work, it'll just be somewhat slower than something like this:
Where the CX ops were something that had to happen anyway and interposing them between the DI load and usage doesn't have any effect on the semantics of the code.
Another thing is with flag setting and usage. Newer CPU's have branch prediction logic that will try to prefetch cache lines of the most likely path to be taken. If you give the pipeline some warning about the conditions of a conditional branch that branch can happen faster.
The setting of ZF happening right before the jump doesn't give the branch prediction much help. If you could interpose some other instructions between the setting of ZF and its usage the branch predictor can do a better job. NAturally, those instructions had better not be …
Since it requires a 100% rewrite of assembly language programs to port from one platform (e.g. 80x88) to another (e.g. AIX Unix), assembly language, by definition, is unportable.
You can always run the code in an emulator like BOCHS, Hercules, QEMU, etc...
A modern x86 CPU can probably emulate a 15 year old mainframe faster than that mainframe ran originally.
That being said, ASM is still important today for anyone who wants code to actually perform well. When you've exhaused all HLL algorithmic optimizations, a bit of hand tuned ASM in the right place can still make a program dramatically faster. Comilers are good, but even the best of them can be beaten by a pro. This is particularly true on the quirky non-orthogonal x86 CPU's, and even more particularly true if the goal is to squeeze size rather than speed so something fits in an EPROM or ROM.
ex. What's the smallest way to clear 10 bytes of memory to zero on somthing 486DX or newer?
fldz fbstp tenbytes
I've never seen a compiler clever enough to figure that one out ;->
;
; Assuming 386 32 bit assembler code
;
mov ecx,val
xor eax,eax ; Counts the number of '1' bits
again:
shl ecx,1
adc eax,0
or ecx,ecx
jnz again
done:
;
; EAX has the count of bits in "val"
;
