| Page 1 of 1 |
|
|
 Posted: Thu, 27th May 2010 20:38 Post subject: Some Assembly question |
|
 |
Hi there person who knows stuff about assembly!
So, for my uni assignments I gotta learn assembly. Not much a problem.
Gota couple of theoretical question that I fail at answering.
Imagine you want to write a compression program. Which of the following parts could be, practically, be written in assembly?
GUI
File input / output
compression algorithm
So for the GUI I just thought it'd be a hell lot more time consuming to write it in assembly, plus the code would be pretty confusing and thus hard to maintain.
Plus it would be system-dependent. What you want your program (which was written on an Intel system) to run on, let's say a PowerPC or ARM system? Well, write it all again, boy.
And I think a whole program written in assembly would be a lot less efficient than if it was written in a high-level language.
(though I guess most of that would apply to all three of those parts listed here)
File in/output:
Dunno about that one. I guess it'd be (mind you, it's my second to third week with assembly so lots of this is just guesswork by some sort of common sense) pretty inefficient. I guess loading a, let's say. 2GB file in assembly is pretty time consuming?
And I have no idea how paging or segmentation would work in assembly. So what happens if you try to load a file that's way bigger than your RAM?
compression algorithm:
(Again, just guesswork) I think a compression algorithm could practically be written in assembly but don't ask me why.
(Why the hell would you ask your students questions like these if they have never ever seen how a comprssion algorithm works? O.o).
So dear person who knows how to write stuff in assembly, feel free to help/enlighten/correct me as you please.
Much appreciated 
|
|
| Back to top |
|
|
LeoNatan
☢ NFOHump Despot ☢
Posts: 73250
Location: Ramat HaSharon, Israel 🇮🇱
|
| Posted: Thu, 27th May 2010 21:03 Post subject: |
|
|
Out of these three, the only one that really fits is the compression algorithm. Otherwise, for the other three you'd have to learn how to interface with the Windows API (for GUI and file I/O), which is certainly possible, but I doubt you'd be required to do that - nobody does that.
|
|
| Back to top |
|
|
|
|
|
| Back to top |
|
|
|
|
| Posted: Thu, 27th May 2010 21:56 Post subject: |
|
|
It's not about really coding that. It's just the question which of those would be pratical.
And if they're not practical then why aren't they?
| sabin1981 wrote: | Now you're just arguing semantics. Getting fucked in the ass with a broom stale is an "improvement" over getting stabbed in the eye with a fork  |
|
|
| Back to top |
|
|
Veki
Posts: 381
Location: Croatia
|
| Posted: Fri, 28th May 2010 08:40 Post subject: Re: Some Assembly question |
|
|
| Reklis wrote: | Imagine you want to write a compression program. Which of the following parts could be, practically, be written in assembly?
GUI
File input / output
compression algorithm |
Compression algorithm would be practical to code in ASM because you want to optimize the code so it runs as fast as possible. That is the advantage of coding in ASM.
Also, coding algorithms is easier that coding GUI in ASM since algorithms can be broken into simple math operations.
GUI and I/O don't need to be fast and/or optimized and writing them in C or some other high-level language is easier that writing them in ASM.
Beware of he who would deny you access to information, for in his heart he dreams himself your master.
Commisssioner Pravin Lal
"U.N. Declaration of Rights"
|
|
| Back to top |
|
|
|
|
| Posted: Sun, 30th May 2010 16:27 Post subject: Re: Some Assembly question |
|
|
| Reklis wrote: |
File in/output:
Dunno about that one. I guess it'd be (mind you, it's my second to third week with assembly so lots of this is just guesswork by some sort of common sense) pretty inefficient. I guess loading a, let's say. 2GB file in assembly is pretty time consuming?
And I have no idea how paging or segmentation would work in assembly. So what happens if you try to load a file that's way bigger than your RAM?
|
You don't need to worry about paging/segmentation or anything else. The winAPI for file i/o AND memory management is very fast and efficient in these operations.
You could assemble in a dll and call its functions from another language's proggy (for GUI)
|
|
| Back to top |
|
|
|
|
| Posted: Tue, 1st Jun 2010 22:54 Post subject: |
|
|
Let's see if somebody can help me with that one until tomorrow morning 
So we use NASM in the class (Netwide Assembler).
I got two 96-Byte numbers, which are in little endian format.
triple1 dd 0x10b70708, 0xffffffff, 0xb20924cf
triple2 dd 0x2d8f44cd, 0x59acf2d8, 0xcd4ab78f
Now. I'm supposed to write a ASM program that adds those two nmbers und saves the result where triple2 is saved (little endian as well).
I'm not allowed to use adc (which would be add with the carry bit). I'm supposed to only use add.
I think I'm supposed to split it up into 3 additions so:
0x10b70708 + 0x2d8ffcd etc.
So I gotta keep track of the carry flag myself. If there's a carry into te non-existant 97th byte the carry bit is to be set.
So if somebody takes a look at this and instantly knows how to do it I'd appreciate if you told me since for some reason I can't even figure out where the triple1 & triple2 is stored nor how I'm supposed to split it up into 3 additions :/
| sabin1981 wrote: | | Now you're just arguing semantics. Getting fucked in the ass with a broom stale is an "improvement" over getting stabbed in the eye with a fork |
|
|
| Back to top |
|
|
LeoNatan
☢ NFOHump Despot ☢
Posts: 73250
Location: Ramat HaSharon, Israel 🇮🇱
|
| Posted: Tue, 1st Jun 2010 23:02 Post subject: |
|
|
Pseudo code:
first1+first2
ifnot carry_flag jump to next1
increase second1
next1:
second1+second2
ifnot carry_flag jump to next2
increase third1
next2:
third1+third2
Something along the lines of this.
|
|
| Back to top |
|
|
TSR69
Banned
Posts: 14962
Location: Republic of the Seven United Provinces
|
| Posted: Tue, 1st Jun 2010 23:32 Post subject: |
|
|
What you published above makes me think you have two 96 bits numbers or two 12 byte integers to add up.
You will have to break it down in little steps.
I once did a prime generator in 16 bits assembler and I never used the overflow function since I kept the arithmetic within the boundaries of 16 bits.
This is an option so you don't have to check for an overflow.
Lets visualize your challenge:
def +
ghi
each char is a 8 Byte integer
I don't know in how many bits you have to program but if it is 64, breakdown all operations to 32 bits, 32 bits integer + another 32 bits integer will never exceed 64 bits (not even if multiply is used).
Hmm okay back to:
def +
ghi
Create an array of integers large enough to hold the information, you need 3 of them, 2 for the base figures and 1 for the outcome, then...
1st op: f+i, store digit, overload? add to e, overload add to d, overload add to c (more intrinsic than d)
2n op: e+h...
Formerly known as iconized
|
|
| Back to top |
|
|
|
|
| Posted: Tue, 1st Jun 2010 23:53 Post subject: |
|
|
Let me put it like that:
Sounds solid (as far as I can follow) but way too complicated. We haven't really touched arrays so I don't think the want us to use them
and to correct myself they are two 96-bit numbers.
Apart from that what I wrote is all the information I got for that task.
@iNatan
Sounds good, only problem is I can't, for the love of god, figure out how to access the three parts of the numbers. I can't figure out where they are stored (which is actually pretty sad :/ )
| sabin1981 wrote: | | Now you're just arguing semantics. Getting fucked in the ass with a broom stale is an "improvement" over getting stabbed in the eye with a fork |
|
|
| Back to top |
|
|
TSR69
Banned
Posts: 14962
Location: Republic of the Seven United Provinces
|
| Posted: Tue, 1st Jun 2010 23:57 Post subject: |
|
|
an array is just a higher programming technique that does not normally exist in assembler
just allocate 36 bytes where you store the variables
Edit: better make it three 13 byte
Formerly known as iconized
|
|
| Back to top |
|
|
LeoNatan
☢ NFOHump Despot ☢
Posts: 73250
Location: Ramat HaSharon, Israel 🇮🇱
|
| Posted: Wed, 2nd Jun 2010 00:07 Post subject: |
|
|
96-bt integer has to be split in registers, probably 32-bit (don't think you'd jump into 64-bit assembly right away). So you need to use 6 registers to sum 2 96-bit numbers.
|
|
| Back to top |
|
|
|
|
| Posted: Tue, 22nd Jun 2010 12:15 Post subject: |
|
|
There we go again (seriously? at the moment I fucking hate assembly).
For this one I need to convert a decimal into BCD. The range is between 0-9999.
for you guys here: think easy, no arrays, no recursion etc.
I'm supposed to only use loops on this one.
I suppose it's easy as pie but I'm not seeing it :/
| sabin1981 wrote: | | Now you're just arguing semantics. Getting fucked in the ass with a broom stale is an "improvement" over getting stabbed in the eye with a fork |
|
|
| Back to top |
|
|
LeoNatan
☢ NFOHump Despot ☢
Posts: 73250
Location: Ramat HaSharon, Israel 🇮🇱
|
|
| Back to top |
|
|
|
|
| Posted: Tue, 22nd Jun 2010 12:50 Post subject: |
|
|
Thanks I think that helps a lot
edit:
wow, I sort of feel stupid for taking about 7 hours to finally get this running the way it should O.o
Though the last 2-3 hours were trying to figure out a couple of kinks that made the program go "what? you want something useful? Take this unholy amount of useless numbers instead!"
Turns out it is quite a stupid idea that, if you are using a loop that decreases a register, to assign that register a new value in the loop *headdesk*
And I thought my mistake was somewhere else entirely.
Just take a guess at how amazingly stupid I felt when I finally figured that one out 
| sabin1981 wrote: | | Now you're just arguing semantics. Getting fucked in the ass with a broom stale is an "improvement" over getting stabbed in the eye with a fork |
|
|
| Back to top |
|
|
| Page 1 of 1 |
All times are GMT + 1 Hour |
