This is a new training app, the first in a raw
for imm. values coding.
I send it before article. It'll be sent soon.
Somehow delay is connected to the fact that
I'm not fine with a way I wrote previous tuts.
I thought that opcode format, position number system,
general approach to low level format and logical
programming control can be discussed as separate
issues.
Now, I think I was wrong, and trying to figure out
new format of tuts.
'Cause opcode format is just an instance of low level
bynary formats and data relation in binary.
And understanding involves understanding of numeric
relations through positions. As for data storage or
for control.

So I'm working on additional set of tuts where
it'll come allong three things as one:
position system, bynary format and writing apps in hex
or bynary from scratch using just hex-binary editor.
Computer does not have anything but numbers, both
for commands, data and control (no jumps - just changing eip
value). It does not have left and right, up and down.
And it makes sick all this "growing down" "shift left" etc. etc.
along with stupid Europian way to spell posiotioning numbers
in left to right descrising order, while every thing else
the Europians enumerate in left to righ increasing order.
This leads to that in bytes order hex digits represent
bits sets in absolutly controversial way
(first digit bits 4-7, next digit 0-3, next digit 8-11! end so on)

OK. All this we discuss later.
Here is the app, I hope some of you will find a use of it.
Posted on 2003-07-05 18:32:37 by The Svin
Hi The Svin,

What about mov segment, r/m16?

Ah of course your application is useful. It is a learning tool. :)
Posted on 2003-07-05 20:10:47 by roticv
What about mov segment, r/m16?

Of course, it'll be discussed as any other opcode formats
that use seg regs. In a time.
Posted on 2003-07-05 20:19:46 by The Svin
Mov segment are start from 8C00. and using D-Bit to reversed it. It only accept 16-bit operand.
Posted on 2003-07-06 04:40:15 by realvampire
Originally posted by The Svin
along with stupid Europian way to spell posiotioning numbers
in left to right descrising order, while every thing else
the Europians enumerate in left to righ increasing order.

I find it a bug in our borrow from the arabs, we took their digits, but we "forgot" to adapt positionning.
take the number 1234
we read it as: one-thousand-two-hundred-thirty-four
but it should be written: 4321 (if they would have done it right)

I think there are some books about this "flaw" in out math, can't remember any author or title though.

(Just of courosity, does the russian math do it "right"? )
Posted on 2003-07-06 06:30:04 by scientica
Yes,scientica.
I absolutly agree with you, it's just another proof how far behind them (and the Indians) we were.
Fibonachi, who the first tried to accept it in Europe, came just too early with it. Now days when in computers for better desing upper digits are in upper addresses - it just shows the buggy porodoxial spelling accepted in Europe wich counts and enumerate from left to write but wrongly spells numbers in reverse order of their positions.
Well when you spell
(2^0)*6 + (2^4)*15+(2^8)*7+(2^12)*9
in HEX
as 97F6h it's worse then
6F79h but at least we got used to it.
But hex editor in bytes order wich
in bytes - > inreasing
but
in order of digits inside the byte decreasing
it looks absolutly nonsence to see
when


9*(16^3) +7*(16^2)+15*(16^1)+6*(16^0)
as
F 6 9 7

not 97F6 (decreasing order)
not 6F79 (increasing order)
but F697 (mixed order to make us nearly blind)


About "russian math" - we have the same notation as the rest of Europe. So there is nothing better.
But I tought my son (without any pressure on him) right way
1. Explaned him what exponts\roots\logarithms are.
(with a simple examles - on powers of 10 and subsequently logs10, and roots of those powers)
2. Explained him that every digit in number is addend has not
one but two values to figure out it's real value - digit itself and
number of position in a row.

So he could spell it any order and found it that increasing
order is better so that hundred twenty three
is better to see as 321
'cause indexing it as
3(0)2(1)1(2)
we can see in () what power of 10 the digit represent.

Saying that the first digit in 123456 is one saying you nothing.
But I want discuss it in another tread with different tuts.
And I'd be happy to have you in the thread for discussion.
Posted on 2003-07-06 13:57:28 by The Svin

Mov segment are start from 8C00. and using D-Bit to reversed it. It only accept 16-bit operand.


Wrong. You can use mov reg32,sreg
in the case upper 16 bits of reg32 will be zeroed.
Posted on 2003-07-06 14:02:13 by The Svin



Wrong. You can use mov reg32,sreg
in the case upper 16 bits of reg32 will be zeroed.



Well its all the same.
Posted on 2003-07-06 19:19:18 by realvampire
What do you mean "the same"?
eax = FFFFXXXXh
then after
mov ax,segreg
eax=FFFFYYYYh
and after
mov eax,segreg
eax = 0000YYYYh
Posted on 2003-07-06 20:07:17 by The Svin
with all opcodes rules i wonder how Intel didn't went Nuts!!
they should have adopted RISC architecture :)
Posted on 2003-07-07 02:46:52 by wizzra
Originally posted by The Svin
Saying that the first digit in 123456 is one saying you nothing.
But I want discuss it in another tread with different tuts.
And I'd be happy to have you in the thread for discussion.

I'll delightfuly participate in the discussion :)

Why don't we start a numerical revolution?!? We start to write three-hundred-twenty-one as "d123", o r perhaps all math teachers will call us heretics and get irritated on us, but the first be hung the highest. :/
Posted on 2003-07-07 06:17:31 by scientica
i Still don't get it, who the hell cares how u said it, 1234 or 4321, i dont see any reason why to even start a thread for it...
just say what u like and be happy with it and let the world uses whatever it wants as long as it works :) ..
i mean, why reInventing the wheel...
Posted on 2003-07-07 09:58:08 by wizzra
Big endian and small endian. The way you read your hexeditor.
Posted on 2003-07-07 10:54:33 by roticv

i Still don't get it, who the hell cares how u said it, 1234 or 4321, i dont see any reason why to even start a thread for it...
just say what u like and be happy with it and let the world uses whatever it wants as long as it works :) ..
i mean, why reInventing the wheel...


Your words just an additional excuse to discuss it deeper.
1. In hex editor you'll see it not as 1234 or 4321
but as 3412.
2. There is not a problem of a way to read it,
the thing is that you enumerate and read from left to right.
But real meaningfull order spelt from right to left.
Thus in European way digits started to has tree values
1 cardinal and two! ordinal.
One of the ordinals - absolutly useless and makes it harder
to understand such a simple thing as pos. num. sys.

For example hundred twenty tree - 123.

When you asked what is the first digit in the number
you'd probably say it's 1.
1 - the first as digit. (first - the first ordinal)
Then what is numeric position?
The numeric position of the 1 is 2nd - it represents number
of 10s in power 2. (2nd - the second ordinal)
and at last cardinal meaning of 1 is 1.

Only second ordinal (2) and the cardinal (1) has sence
in arithmetic meaning cause 1 in 123 means 1 ten raised in 2.

Now about "the world" you are wrong, - only a part of the world is affected. And the part uses it badly in average.
Though it very simple thing. Before you even think to answer me - read how many people asked before why bytes in dword
are in reversed order?
The question itself shows that the people themself
don't understand that there are two different things
1.Positioning numbers that has addends with two values -
position (log of radix) and cardinal values of the addend.
2. Spelling of the numbers in some hex editor or debugger
or asm source.
I bet some of them think that bytes are placed in rows of
left to right as they see in dumps showed in editors.

Ok, I'll give you example.
Here is array of dwords.
You see some hex editor value in bytes:
83 17 04 BC

You know the the four bytes is address of the dwords array.
Now you see five different values of dwords, also in bytes
and those values are also represent addresses of some data
0F 34 19 BC
B3 AA AA FC
A4 12 34 BF
03 FF FF FF
1B 34 19 BC

Array may be long or short - we don't know it.
But we can say for sure that one of the five values - can
not be address of any dword from the array wich (array) starts from address
83 17 04 BC.
Can you tell me what is that value that can not be address of
dword member of the array.
And explain - how you know it.
And if it is easy to guess from the spelling.
Posted on 2003-07-07 15:34:01 by The Svin
just a small question:
1. In hex editor you'll see it not as 1234 but as 3412.


wasn't it because 12 is the high order, and 34 is the low order, and high order goes to the high order of addresses and same for low order?

num=12345678

offset:
00 01 02 03
---------------
78 56 34 12


as for the question below, i dont really get what u mean, but i go for: 03 FF FF FF
-> FFFFFF03 , sits in an memory address which cannot be accessed..
but i think i did it wrong, so execuse me.
Posted on 2003-07-07 16:17:51 by wizzra
Well, neither of 0xFCAAAAB3, 0xBF3412A4 or 0xFFFFFF03 can be. The 0xBF3412A4 suggests that the table stops somewhere before this address since it is not aligned with the data. It isn't much harder too see than if it had been written out as DWORDs. Your brain will get used to rearranging the bytes automatically after a while...

There are probably some advantages to writing numbers with the LSB first, but then old people would get confused.
Posted on 2003-07-07 17:10:02 by Sephiroth3
83 17 04 BC is bytes of dword that is address of the start of
the array
in left to right increasing order
it's
BC041783h
Any of (in bytes order) dwords
0F 34 19 BC
B3 AA AA FC
03 FF FF FF
1B 34 19 BC

can be address of some member of the array
we can also calculate index of dwords
pointed by those addresses
as
(x - BC041783h) shr 2
for example for
03 FF FF FF (FFFFFF03h)
(FFFFFF03-BC041783) shr 2 = 21FDF3C0
If array would be very big then member x[21FDF3C0]
would have address FFFFFF03h

Yet,
A4 12 34 BF (BF3412A4h) could never be address
of any dword in the array.
Why?
Posted on 2003-07-07 18:26:52 by The Svin
Well the thing is, that since all 5 are addresses of some data, then it is highly probable that the BF3412A4 points to something entirely different. The two that are above it must then also be something else.
Posted on 2003-07-08 08:38:53 by Sephiroth3
Why don't we start a numerical revolution?!?

scientica,
we could write numbers as we want,
I just want to clarify why I started talking
about it in the first place.
I were about start another set of threads
about
- Usage of specifics of pos. num. sys.
- Pure hex\binary coding (including data and haders)
- All the above connected to such a thing as "binary format"
and the term include in itself binary opcode format among
other formats.
When discussing it, there would be examples and exersizes,
and they would be done in some TOOLS.
My point is - that we can not change the way in wich binary
data represented in those TOOLS, but for successfull coding we need understand
difference between binary data itself (wich include values and
position of the values) and representation of the data (or spelling)
of the data in the TOOL (hex editors etc.).
Language affect the way to think.
Spelling is a part of language and also
affect the thinking.
I want to discuss binary coding not to torcher ourself,
but from the way coding itself show how it helps to discover
or clarify something in very simple way wich seemed blured and
complex before (coding in HLL or mnemonics ASM with a lot of
work done not by a coder but by a translater and linker)
So talking of spelling positioned numbers was kind of
small difficulties that that lay in the road.
For example when you need mov ax,109h
you would think of 109h as
(1 time 256 + 9 ones)
and then spell bytes in hex editor.
B8 09 01.
Thinking this way while spelling:
B8 - mov ax (1011- mov imm 1 - full regs 000 - ax)
09 - 09 ones
01 - and + 01 time 256.
This way don't spell it as
B8 01 09
or
B8 09 10

But overcoming those difficalties is actually not a problem
but the way to make something important clear and then use
this "something"
:)
I've just thought I'm going beforeahead.
It would be more clear after first articalls in a new thread.
Posted on 2003-07-08 13:51:09 by The Svin

Well the thing is, that since all 5 are addresses of some data, then it is highly probable that the BF3412A4 points to something entirely different. The two that are above it must then also be something else.

Yes, of course, I'd just want you to explain others in numeric
way why BF3412A4 points to something entirely different.
It would be a good example why byte spelling representation
of dword might not be a good way to show data (to look and
see interesting data in numbers in natural way).

I'm sure you mean last two bits of the dwords value.
And if we have an interest in them (bits 0 and 1), we
(keeping in mind "last bits") more naturally would look at
at first hex digit or (less natural yet we could get used to it) -
to last hex digit.
But dword in bytes representation (bytes of dwords in
increasing order, yet hex digits in byte in decreasing order) we are forced to look not at first or last hex digit, but at the second.
That's why for example, making your point clear, I think, you
rewrote those byte-spelled dwords in just left to right hex digits decreasing order, to make it clear - placing hex digit
with low bits at last (rightest) place of number.
Posted on 2003-07-08 14:05:12 by The Svin