I am having trouble with the following question.
I have tried to figure out what the code says
Allocate 32 bytes of memory to source_block and do NOT initialise
Allocate 2 bytes of consecutive memory to rslt and initialise with 2 and 3 respectively
Allocate 2 bytes of memory to rslt 1 and initialise with the value 3

Posted on 2011-09-15 07:54:16 by and1_hotsauce
This is CLEARLY a 'homework' question - did you expect us to do your homework?
I won't lock the topic yet, I could be wrong, but I think I am right.
Posted on 2011-09-15 11:26:04 by Homer
Locked. Sorry.

What you need to do is fill in the values inside the rectangular sections with "what the description says".

Seriously. Open the book and read past the foreword.
Posted on 2011-09-15 15:44:12 by JimmyClif
I am posting here again since my other thread was locked for no reason and I cannot message the moderators

I am having trouble understanding the concept of this question. I know that the code says :
Allocate 32 bytes of CONSECUTIVE memory to source_block and do NOT initialise
Allocate 2 bytes of consecutive memory to rslt and initialise with 2 and 3 respectively
Allocate 2 bytes of memory to rslt 1 and initialise with the value 3

How can I do this? I am guessing that each 'rectangle' is 8 bytes long. So I would need 4 boxes for source_block

With rslt and rslt1, I have broken each rectangle into 8 blocks and I have initialised the first two blocks with 2 and 3 for rslt and the first block, 2, for rslt1.
Is this correct?

note: JimmyClif in future please do not be saracastic and assume that I have NOT read the book. I have read PAST the 'foreword' section. Just because you read the book does not mean you will understand all the theory that is presented in there.
Posted on 2011-09-15 17:56:22 by and1_hotsauce
Andy HotSauce,

I am sorry if I came off as sarcastic but seriously anyone who hands in work like this:

didn't put in a fair effort. Some byte slots are twice the size as others?

Behind those rectangular boxes it shows you how many bytes should be inside the block and to fill it with the correct values shouldn't be all too hard.

I would suggest making yourself a hex grid on graph paper (the paper with those little squares) and start writing in each square a number according to where everything is.

[00]-[01]-[02]-[03]-[04]-[05]-[06]-[07] (next line)
[  ]-[  ]-[  ]-[  ]-[  ]-[  ]-[  ]-[  ] (here we'd have bytes)
[08]-[09]-[0A]-[0B]-[0C]-[0D]-[0E]-[0F] (next line)
[  ]-[  ]-[  ]-[  ]-[  ]-[  ]-[  ]-[  ] (here we'd have bytes)
[1F]-[20]-[21]-[22]-[23]-[24]-[25]-[26] (see something odd here compared to the ones above?)
[  ]-[  ]-[  ]-[  ]-[  ]-[  ]-[  ]-[  ] (here we'd have bytes)

then I would start filling the byte pattern up with 32 non initialized values. After those I'd be putting more values.

I don't think it said to halfassedly draw a few lines and color something else green.

You can also just assemble the data segment and have a look and copy those into the squared boxes without ever trying either.

It's not the fact that I read the book - trust me - I didn't read _your_ book. It's the fact that some people put effort into their work and some don't.
Posted on 2011-09-15 18:53:30 by JimmyClif
ok thanks! the method you proposed is very logical. I did not think to set my work out like that

andy hotsauce
Posted on 2011-09-16 08:13:05 by and1_hotsauce
It seems I am still having trouble with this concept
For eg.
data  segment
db 10H
data ends

This is some of the assumptions I make:
10H together is one byte
Each memory location is byte wide

The book says "reserve one byte of memory and INITIALISE with value 10h". Does this mean the whole row gets initialised with 10 like below?

[0000]-[0001]-[0002]-[0003]-[0004]-[0005]-[0006]-[0007] ***memory location
-[10]--[10]---[10]----[10]---[10]--[10]----[10]---[10] ***Contents
Posted on 2011-09-22 01:27:21 by and1_hotsauce
Yeah I was right - its a homework question, but that won't stop me helping out since you clearly need someone to throw you a rope! If you need to ask specific questions, create a new thread and ask them, one at a time, and bring your experience back to this thread, if you feel there is anything left to wonder about.
The trailing 'h' indicates that the value is in fact hexadecimal - and any hex value of two digits is one byte. In this case, the value 10h indicates a decimal value 16. To get our hands more dirty, each digit of a hex value is 4 bits.
You need to study number systems?

Further, a hint was given that some of the slots are bigger than the others, indicating that they contain more bits than the others... perhaps they are 16-bit words instead of 8-bit bytes? ;)
Posted on 2011-09-22 04:21:46 by Homer
You'll be able to message users and do other stuff once you've reached a minimal number of posts, it's one of our mechanisms to guard against spam, and the number involved is currently reasonably low. It's a small impost apon our newest members, in order to prevent our site being used as a defacto spam service to attack our users!

Posted on 2011-09-22 04:28:55 by Homer
No - only 1 byte gets initialized with 10h - all the other fields are uninitialized 0h.
Posted on 2011-09-22 09:47:58 by JimmyClif
Yeah... "db 10h" initializes only one byte, but "dw 3" initializes two bytes (16 bits, one "word") even though 3 would fit in one byte. Since x86 is "little endian", the 3 comes first - the "high byte" of the "word" (0) comes second. The documentation for your assembler should explain the meaning of "db", "dw", "dd", etc.

The "(?)" does say "don't initialize", but I think you'll find that these bytes (two bytes per "word" - you want 16 words) are, in fact, initialized to zero(s).

It can be confusing at first, even if you've read the book. Stick with it - it gets easier! Assembly language, by its nature, is actually "simple"... but you need to learn a whole lot of "simple" stuff all at once to get started!


Posted on 2011-09-22 14:52:41 by fbkotler