Assembly Language

No one visiting here seems to read the site rules. This is not a homework site.

Its not a homework

I found these in Assembly Language Book and I'm just looking for a solutions .

Thank you

The same book, if it is of any value should illustrate the solution( s ).

Only a course TEXTBOOK, to my knowledge, posts questions without answers.

Every even integer greater than 2 can be expressed as the sum of two primes.

I'll leave the proof as an exercise for the reader.

How much you paying?

Tools for you....

http://www.freebsd.org/doc/en/books/developers-handbook/x86.html

http://www.cs.virginia.edu/~evans/cs216/guides/x86.html

http://www.cs.dartmouth.edu/~sergey/cs258/2009/x86_newnew.pdf

Thank you my friend for your help

The question doesn't make sense as it doesn't say how you input or display data. Assembly language has no such commandes. You have to write your own input routine to read say button pushes on an input port and to output data onto a port which goes to some sort of peripheral.

First ever assembly language program I wrote was for a PDP11 ? it had data input on key switches and the answer read out on the lamps.

Del

Thank you for you help :)

Years ago, I would have programmed the whole lot in GBASIC, tested it, all within a 4 - 6 hour window.....

Then once it worked exactly as required, I would have assembled/converted the now tested & working GBASIC program to allow it to run faster in machine code........though it would be probably bigger and not as fast in execution as a properly written assembler only program.....but who cares.....?

Written directly in assembly for say a home computer with a Z80 for example, but taking maybe a week of spare time, assuming I am allowed to include/use any routines that I have already.....

40 Years ago for example, a good programmer managed, on average, to write between 1 and 5 lines of FULLY TESTED code a day.........expensive stuff software.....

I never liked assembly language because it's not portable at all. Every processor has its own. Oh, and it takes a lot of effor to do not much.

The input/output is the big pain. The core processing of each question is pretty easy.

#1 is addition: l+l+w+w. You don't even need to look up the "multiply" instructions. :)

#2: AND-ing a number with 1 will tell you whether it's even or odd (result = 0 means even).

Careful with #3. Concatenating strings means making sure your destination buffer has enough space for both. Don't just copy INSTR2 to the end of INSTR1 unless you know you won't overwrite useful data.

#4: You don't need to store all the numbers. Start with min = "very large number" and max = "very small numnber." For each number read, if it's < min, set min to the number. If number > max, max=number.

#5 is straightforward.

"Oh, and it takes a lot of effor to do not much" - depends how fast you want it to run, and how big you want the code to be. If time and memory size no problem, then I agree. If you want it to fly and squish (how did they do video games on a 4MHz/4Kb RAM 8 bit machine?) then assembly language is the way to go.

Sometimes just a tiny bit of code - equating to one or two lines of HLL code, especially in a loop - can be optimized in assembler to make all the difference to an application's performance.

You have a fair point. Video game programmers are always trying to out-perform each other (and themselves), so even with a PS4 they're still optimizing small chunks of code.

But try to write "Halo" in assembly language.

Waaaay back when I programmed an emission tomographic body scanner in assembly language, including real-time deconvolution and back-projection of the image data. Took a while, especially the hand-assembling into machine code bit.