-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vince L wrote:

On Saturday 02 June 2007 04:22, azeem ahmad wrote:

...

hi list i am about to make a bootable floppy for test but i am being unable to get it done please review the code below and tell me if there is any problem with it

Very funny!!! I have recently left a job in part because I became very tired of reviewing rubbish code in assembler when I felt certain I could write the same thing in C and leave less problems if my C was unreviewed than there would be if I reviewed someone else's misguided assembler.

Any high level computer language comes with overheads on the compiled code, and I have seen in the past seen some truly horrible low level code generated by high level language compilers. Also on occasion in the past I have found decompiling to assembler and hand optimisation was a necessity. Some assembler code is truly ugly (using 100s of NOPS for timing is one example I can think off), where timing or speed is essential one will nearly always get a better result with well written assembler (it often is not pretty to look at at).. One would assume in your role as a code reviewer you were not only taking into account what the code did but how well it did it. (If not why not?). <snip>

...

call _disp # call subroutine disp Useless comment. Says what you can see from the code

...

_disp: #label of the disp routine That too is a useless comment. Again, either we know it's a label, or we have nothing useful to contribute to a review. No comment is needed here, it just makes the rest harder to read.

...

lodsb # load the string pointed by ds:si in a # - byte by byte manner into the accumulator This is a misleading comment. You should be shot for this. AFAICS, this instruction loads just 1 byte, it does not do anything byte by byte - it is the _disp loop as a whole which does byte by byte.

...

jz ret # jump if al zero to return Another useless comment for the same reason. I am not hot on Intel assembler,

Obviously not, see below! jz checks the status of zero flag

so I don't know it is al which is zero compared - but I do know that to review this I would have to know what jz does - so as reviewer, I know it is my responsibility either to understand each line or to find out what it does

...

or %al, %al # check if the entire string has been loaded byte-wise # by oring al to al, # if the result is 0, there are no more bytes to load

Really useful ... swapped the order of instructions .. or al,al will set the Z flag to zero for the jz test. As you have ordered them this routine could go on for ever. If you do not know about it, dont comment on it.

This is a far more useful comment, because it reveals strategy - ie what you

<snip> This a bog standard Intel interrupt 10h display routine which could be lifted out of any 8086 assembler cookbook. It does and should not need any more comment that. Comments are a matter a style, personally I dislike end of line comments (they get in the way of the code), and prefer block head comments. However, for a novice, which the guy obviously is, the comments are probably a good mnemonic. My suspicion is the original got mauled in transmission. The only comment I made on it was a suspicion that a dangerous assumption was being made with the string definition, which is probably an easily made mistake by a novice assembler programmer with a C background.

If your intention is to make a bootable floppy, you may find this link useful: http://linuxgazette.net/issue84/dashti.html. Good luck with your coding - but even if you are fixing the comments in this code, you've had your 5 minutes from me. May be this is not the help you expected - I have been been hard on your style - but I hope that it will help you in the future.

I would suspect that he attempting first steps in using assembler to communicate with the PC BIOS. Something which is usually rather difficult to do on both the Linux and Win32 platform. Using 8/16 bit intel assembler in useful start point, rather than the 32 bit instruction set. There are also quite a view 8088/8086 devices out there in the process control world. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGYpH2asN0sSnLmgIRAs2ZAKCWlvIqzBZYRx2g8ouf4aZKBPaVOQCgy4tN 9feZSHVXJuVkYkkk4FWLqEM= =RJnh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 03 June 2007 04:01, jdd wrote:

G T Smith wrote:

...

Any high level computer language comes with overheads on the compiled code

if you need to have complete control over a very fast and compact code, think about 'Forth' langage

Now I _am_ gagging. If speed is an issue, a purely interpreted language (unlike contemporary JVMs which perform native code translation) will never give good speed. And that hideous code formatting scheme. Yuck.

jdd

RRS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

jdd wrote:

Randall R Schulz wrote:

...

If speed is an issue, a purely interpreted language

Forth is not an interpreted langage. only uses a small number of assembly langage function and recursive calls.

No, the Forth text is interpreted once into bytecodes, then the bytecodes are interpreted from there to execute the machine code functions. Still interpretation, but much faster. Just like Billy G's original Microsoft Basic in the early '80's. But any new function is

added to the underlying system and available instantly, and all this is done function by function. very simple for structured programming.

True enough. I was fascinated by Forth for a while, but never got to use it professionally. John Perry -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 03 June 2007 14:53, Jerry Feldman wrote:

On Sun, 3 Jun 2007 08:05:00 -0700

Randall R Schulz wrote:

...

If speed is an issue, a purely interpreted language (unlike contemporary JVMs which perform native code translation) will never give good speed.

Actually, I've seen well written Forth code do very well. We had a 3270 terminal emulation system on an 8085 processor where we bit a system with Forth as the high level language, and Forth did very well, albeit that Forth is interpreted, and did better than the assembler language version of the same emulator product.

That undoubtedly says more about how hard it is to write assembly than it does about the inherent speed potential of FORTH vs. assembly. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 03 June 2007 07:59, Jerry Feldman wrote:

On Sun, 03 Jun 2007 11:03:34 +0100

G T Smith wrote:

...

Some assembler code is truly ugly (using 100s of NOPS for timing is one example I can think off), where timing or speed is essential one will nearly always get a better result with well written assembler (it often is not pretty to look at at)..

Just a general comment on this since I was one of the authors of the Unix/Windows NT assembler for the Alpha chip. (This is a bit of a generalization) Alpha chip could execute multiple simultaneous streams (2 or 4 depending on the chip version), but the instructions had to be ordered properly for this to happen. We used a "scheduler" as an optimization as the last pass of the assembler. In some cases, using NOPs had a positive performance effect. Additionally, in the Intel Itanium chip, they pack 6 instructions together, and properly placed NOPs help performance.

And the real point for any modern microprocessor is that it's very difficult for human programmers to properly optimize the instruction streams when writing in assembly. Assembly programming's domain continues to shrink with the ongoing advancement of both processor and compiler / programming language technologies. Combine this with the need for increased programmer productivity and assembler is left with littler more than niche applications. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

James Knott wrote:

Anyone here remember doing assembly code in DEBUG? Many years ago, someone wanted a DOS utility that would just return an error code and do nothing else. I wrote one in assembler, using DEBUG, and it was only 5 bytes long. The same thing in Turbo C, came in at a few K bytes.

I used debug to brake applications. I had some that copy protection made crash... Just a story. I had to compile a progam to have a computer hard reset. I first do a basic programm... two lines, but 64k basic to launch. Then a turbo pascal exe. down to 10K Tene a macro assembler .com... 2K then I took a hex program and wrote the code for Longjump<hardresetaddr>... 3 bytes, and fast!! :-) jdd -- http://www.dodin.net http://gourmandises.orangeblog.fr/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Mike McMullin wrote:

On Sun, 2007-06-03 at 07:43 -0400, James Knott wrote:

...

M Harris wrote:

...

On Friday 01 June 2007 22:22, azeem ahmad wrote:

...

i am about to make a bootable floppy for test but i am being unable to get it done

Whoa bubba... I am surprised you can make lunch... but seriously, who taught you how to write assembler code? Ok, here is a sample "hello, world!" program that includes a counted loop to the iolib wrapper routine ( hello.asm ) and the io wrapper ( iolib.asm ) and a Makefile. All you will need to build this hello world demo in opensuse is yasm|nasm , binutils ( ld ) and elf (standard). Its a flat 32 bit sample, staticly linked, and does not call any of the c library. Enjoy, but pay particular attention to the format, the style, the comments, and the Makefile. note: do not include the /begin /end lines in the code files.

Anyone here remember doing assembly code in DEBUG? Many years ago, someone wanted a DOS utility that would just return an error code and do nothing else. I wrote one in assembler, using DEBUG, and it was only 5 bytes long. The same thing in Turbo C, came in at a few K bytes.

Anyone here learn a.l. by hand disassembling their basic interpreter? Someone mentioned that this looked like an effort on the part of person looking to learn assembly, to me that makes sense, and should signal the "vultures" to provide some actual guidance on getting the code runnable, and then perhaps crank over the style, which will come over time as the person gets used to assembly language.

While not quite the same thing, I manually typed in my BASIC interpreter, in octal! My first computer was an IMSAI 8080 and I ran Scelbi's "SCELBAL" BASIC on it. Since I didn't have a paper tape reader, the only way I had to load it, was to type the octal numbers into memory, using Scelbi's monitor program. Once I'd typed in a block of 256 bytes, I'd save it to cassette tape and then start on the next block. Fortunately, my work had me in the middle of nowhere for a month, so I had plenty of spare time on my hands. I also loaded in that monitor program from the front panel and then saved to tape! IMSAI 8080 http://oldcomputers.net/imsai8080.html -- Use OpenOffice.org http://www.openoffice.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 03 June 2007 12:43, James Knott wrote:

Anyone here remember doing assembly code in DEBUG? Many years ago, someone wanted a DOS utility that would just return an error code and do nothing else. I wrote one in assembler, using DEBUG, and it was only 5 bytes long. The same thing in Turbo C, came in at a few K bytes.

A lot of that depends on what library elements get compiled in by default, and how much you could strip that down. If you wrote the core of this functionality in a separate C file, the size of the resulting object file would be more indicative - the trick would be either to compile main() without all of the overheads, or find a shortcut to invoke the requested function, and link that instead. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 03 June 2007 17:23, James Knott wrote:

I was just learning about C programming at the time, so neither trick would have been known to me. I also learned about the "fun" of variable sizes. In class, we were using Borland's Turbo C++ for DOS. At home, I was using Borland C++ for OS/2. I'd do my homework and it would run fine on OS/2, but fail when I got to class, because of the difference in integer size etc.

Those were the days. Innumerable fights with pointers... Doing C while never having been given an explanation of what the compiler did, ie Preprocess, Compile, Assemble, Link.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 03 June 2007 18:06, jdd wrote:

too many oldtimer, here :-)))

Punched cards, anyone? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

...

too many oldtimer, here :-)))

Punched cards, anyone? My first "official" computer related job (ca. 1970, I was 15) was computer operator on an IBM 360 mod44 (fully transistorized high speed number crunching mainframe--- with 256K of main ram!). At the time there were only 11 of those models in the world. The one I worked on sat on the 2nd floor of Upsher's Laboratories in Kansas City. That sucker had a high speed mag tape reader, high speed yellow punched tape reader, and of course a turbo punched card hopper. We eventually installed drive packs... with platters the size of a large cake pan... and the drive units were the size of a washing machine. The whole thing sat on a raised floor, required its own building circuit... and was cooled by three air-conditioner units mounted on the roof. The lab used the unit primarily to analyse electro-cardiograms from the four-state area hospitals. The programming (I must have punched a zillion cards in the early seventies...) was Fortran II / IV .... we had an entire room of card cabinets. Oh, and the best part were all the blinking

On Sunday 03 June 2007 13:43, Vince L wrote: lights... that thing had the primary registers "lit up" on the front panel... selectable with a large wheel switch... and of course the stdout device was a Selectric 1 console. The last time I saw an IBM 360 mod44 was at the Chicago Museum of Science and Industry... in the IBM wing... behind a glass case. <sigh> That was the machine that brought T.J. Watson Jr fame for saying, "from this point on we will never make another computer with vacuum tubes!" And the second famous quote when his son asked him what they were doing down at the lab... he said, "I have no idea... but whatever it is they're doing it at 300,000 times per second." I still remember vividly about dreaming of a time when I might own my own computer ... and be able to do anything I could imagine with it... -- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 03 June 2007 13:43, Vince L wrote:

On Sunday 03 June 2007 18:06, jdd wrote:

...

too many oldtimer, here :-)))

Punched cards, anyone?

You mean in Fortran IV times ? ;-) -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jerry Feldman wrote:

On Sun, 3 Jun 2007 15:36:06 -0500 "Rajko M." wrote:

...

You mean in Fortran IV times ? ;-)

I learned FORTRAN II just before FORTAN IV was released on an IBM 7044.

Worked with a 4K DEC PDP 8. Had to enter binary for the RIM loader to load in paper tape. The original Burger King point of sale (Manex) was developed in the early 1970s. Very tight 100% assembler code with no external storage. It relied on core memory for persistence if power went down. The modem did not have any UARTS, we would send a bit, go into a timing loop for 1200 bps, send the next bit until 8 bits + start and stop were sent. We even had to program the hammer strikes on the printer drum.. Those days were fun.

I also used to work with a PDP-8i and remember the RIM loader. -- Use OpenOffice.org http://www.openoffice.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

...

...

...

...

"Vince" == Vince L writes:

Vince> On Sunday 03 June 2007 18:06, jdd wrote:

...

too many oldtimer, here :-)))

Vince> Punched cards, anyone? If we are playing that game.... I wrote my first programs 49 years ago for a Pegasus computer -- no high level language, no assembler, size of a house and using valves (tubes to the Americans). 39 bit word, and 32 words of memory. Never got to understand the delay-line stuff, but I was quite young. Tape, cards, switches .... first UK on-line system, seem to have done it all. Loved assembler; adored microcode. Miss real Lisp, and end up writing C. ==John ffitch -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Anyone here remember doing assembly code in DEBUG? Back in the mid '80s we used "debug.com" at the Tampa lab to efficiently send

On Sunday 03 June 2007 06:43, James Knott wrote: printer control codes to the new line of Proprinters by IBM. The same thing could be done with some trouble with Rom BASIC... but the simplicity of calling the bios from a com file for configuring a printer control stream couldn't be beat... A buddy and I were all ready to right a "new" debug clone for linux (32 bit). But after getting used to yasm, and gdb, we decided to forgo the effort. For those of you who never used it, debug was a combination of debugging tool (register display) and machine language monitor. It was the latter that most folks were unaware of usually... early .com files could be written quickly that would run hundreds of times faster than interpretted counter parts... and back then all we really has was BASIC, and some rather early level expensive Pascal from Borland and others. Assembler is having a bit of a revival these days because of the full 32 bit flat memory model provided by linux (no worry about segmentation or near/far calls etc) and the fact that the C library can be used with it almost transparently. And for some of us--- messing around with the guts of the processor is just plain fun... -- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

jdd wrote:

M Harris wrote:

...

For those of you who never used it, debug was a combination of debugging tool (register display) and machine language monitor. It was the latter that most folks were unaware of usually... early .com

and breaking an application was a problem of minutes :-)

to have an idea, try "ed", still present on openSUSE

man ed ed is a line-oriented text editor.

exactly the same than debug was working with

jdd

When I started in computer it was paper tape, punched cards were an advancement. The first "PC" I built was an IMSAI 8080 (serial no. 25), and used a Model 10 Teletype as a terminal. My real world work started with transistor machines (RCA Spectra 70 Model 55), and just missed the vacuum tube machines. Well almost, I learned to maintain a GE vacuum tube monster. Bill Anderson -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org