How to move AROS forward

[ffastback]

paolone wrote:

1. just whining and claiming their opinion would be the best way to improve AROS

2. contribute with code to reach the common goal stated above.

3. take the existing code and improve upon it the way they like, just to become the new ruler of the world.

The direction is already here for the people that want to see it. The others may disagree, but please don't claim AROS is pointless or directionless anymore, as it is completely untrue.

How about adding:

4.  If you can't program, donate to an AROS bounty, even if $1.

[Belial6]

"I'd be happy if they did break compatibility and provide a sand-box for old apps. While they're doing that, they might as well break other stuff to allow SMP, and to lock off user programs from accessing OS structures. "

I agree with you.  Of course this brings the conversaton back to the forking argument.  The point of not breaking compatibility is so old software could continue to run.  Right now, we have to rely on AInc to run most old software because they own the Kickstarts.  My primary interst in AROS is that I keep hoping that it will eventually get reported to the 68k, and we could finally get rid of AInc.  

I guess the way I see it is that for any old software, I want to be able to run it on my MiniMig, one of it's successors, and maybe UAE.  For new software, it doesn't matter if we break compatibility with the old API.

To answer the original questions:

1. Can it be done?
Yes.

2. Can it be done elegantly?
Sure, if Aros was ported to 68k so that we don't have to go to AInc to get kickstarts, and UAE were integrated so that it worked out of the box using that port it be plenty elegant.

3. Should it be done?

That is the question.  I would say it would make sense, but that the 68k port is far more important than it is given credit for.

[saimon69]

@HenryCase
I want to apologize to had pbrought the old discussion out, if only i knew was going to do such a mess, but maybe is better this way, so the ideas were put under verification.

Actually from my point of view i might be simply appy if the modifications made by Michael were ported to the base x86 build; i know through the developer mailing list that staf is rewriting the ABI therefore, considered that the programs made so far will require a rewrite anyway, better to include even those modifications to the tree.

@FairlaneFastback
Is my intention to contribute to some of the bounties, in particular would like to see a bounty to bring some basic office application on AROS as siag office or similar and guess who else might be interestedin such a bounty....

Saimon69

[HenryCase]

@all
Thank you for your posts.

@bloodline and @SamuraiCrow
I would like to pick up on one point which has been stated by you both in the past, which is that there isn't a way to distinguish between instructions and data. In my admittedly limited understanding of the subject that seems like complete tosh, so forgive me whilst I persist with my questioning to discover who is mistaken.

According to Wikipedia, the following four steps are used in classical CPU architecture: fetch, decode, execute, writeback. The second step 'decode' is of interest to us here. Again, according to Wikipedia:

"In the decode step, the instruction is broken up into parts that have significance to other portions of the CPU. The way in which the numerical instruction value is interpreted is defined by the CPU's instruction set architecture(ISA). Often, one group of numbers in the instruction, called the opcode, indicates which operation to perform. The remaining parts of the number usually provide information required for that instruction, such as operands for an addition operation."

So for even the most basic program to function the CPU must know the difference between the opcode part of the instruction and the operand part of the instruction. Can we agree on that at least?

saimon69 wrote:
@HenryCase
I want to apologize to had pbrought the old discussion out, if only i knew was going to do such a mess, but maybe is better this way, so the ideas were put under verification.

No worries mate, I'm glad you did bring back this old discussion as it has been helpful for me.

saimon69 wrote:
i know through the developer mailing list that staf is rewriting the ABI

I took myself off the AROS mailing list, but I am curious to know how Staf is getting on with writing/rewriting the ABI. Any news you know of on that front?

[yakumo9275]

HenryCase wrote:
I would like to pick up on one point which has been stated by you both in the past, which is that there isn't a way to distinguish between instructions and data.

They are right, there isnt.

In my admittedly limited understanding of the subject that seems like complete tosh, so forgive me whilst I persist with my questioning to discover who is mistaken.

You lack a basic fundamental understanding of how a cpu operates, so this thread goes around in circles when people say no, you say yes.

According to Wikipedia, the following four steps are used in classical CPU architecture: fetch, decode, execute, writeback. The second step 'decode' is of interest to us here. Again, according to Wikipedia:
.....
So for even the most basic program to function the CPU must know the difference between the opcode part of the instruction and the operand part of the instruction. Can we agree on that at least?

The cpu does know the difference between the opcode bits and other bits of the bytes it loads. The problem is that the cpu just loads a stream of bytes into its decoder. it looks at the bits and says mmm these 5 bits mean xor... I'll go run the XOR opcode. it doesnt know what its decoded is a string of text. It loads whatever the instruction pointer is pointing at. If things get really bad, it throws an exception.

[HenryCase]

yakumo9275 wrote:
You lack a basic fundamental understanding of how a cpu operates, so this thread goes around in circles when people say no, you say yes.

The idiot (like me) knows no limits, which is a strength as well as a weakness.

The cpu does know the difference between the opcode bits and other bits of the bytes it loads. The problem is that the cpu just loads a stream of bytes into its decoder. it looks at the bits and says mmm these 5 bits mean xor... I'll go run the XOR opcode. it doesnt know what its decoded is a string of text. It loads whatever the instruction pointer is pointing at. If things get really bad, it throws an exception.

"I'll go run the XOR opcode", so in other words I'm right.

The CPU has the ability to recognise an XOR opcode, and every other opcode it uses, and if part of an instruction isn't an opcode it is data. Therefore a CPU knows, after the 'decode' process, what is an opcode and what is an operand, correct? This requires just a yes or no answer.

[A6000]

When the CPU reads a memory location or a block of memory, it fetches something like this:-
1011001 11001100 11101010 00110110 01101111 00001110

the only way to interpret this "data" is to know what the CPU is expecting.

HenryCase wrote:
I would like to pick up on one point which has been stated by you both in the past, which is that there isn't a way to distinguish between instructions and data.

Every program has a start point and the CPU knows this start address WILL be an instruction (opcode) but the second byte maybe another opcode or it could be data.

According to Wikipedia, the following four steps are used in classical CPU architecture: fetch, decode, execute, writeback. The second step 'decode' is of interest to us here. Again, according to Wikipedia:
.....
So for even the most basic program to function the CPU must know the difference between the opcode part of the instruction and the operand part of the instruction. Can we agree on that at least?

So the only way for the operating system to know if a byte contains an opcode or data is to emulate the cpu in software and follow the execution of the program from the start, which will be very slow, it cannot simply read a byte and know whether it has fetched an opcode or data.

[yakumo9275]

HenryCase wrote:
"I'll go run the XOR opcode", so in other words I'm right.

The CPU has the ability to recognise an XOR opcode, and every other opcode it uses, and if part of an instruction isn't an opcode it is data. Therefore a CPU knows, after the 'decode' process, what is an opcode and what is an operand, correct? This requires just a yes or no answer.

Sure it knows, this is how emulators like EUAE run.

x86 for example, uses all 256 'bytes' as master opcodes. That means 'A' is an opcode and 'B' and 'C' and 'a' and 'q' etc. EG: "Edgar Allan Poe" is it text or is it data? Could be valid as both, or one or the other. You cant arbitrarily lable it as either.

Back to your example, say on powerpc, XOR is encoded with 5 bits, so after the 'decode' process, the 5bit XOR opcode is out, the processor is left with 26bits.. only they are not data, its still the same opcode. (all ppc instructions are 32bits).

The problem is, code and data are ambiguous, they are the same thing. There is no rule that says code can not be data or data can not be code in a binary image. The processor _assumes_ its code.

I can see this is fruitless so I'm going to stop replying. I hereby agree with all you say, you are correct, we are all ignorant. Yes memory protection is so easy to add to amiga os, we can trap pointers, detect valid opcodes in a sea of data, magically understand self modifying code and can beat gary kasparov at mahjong with our eyes closed!

I'm done, stick a fork in me.

[Hans_]

HenryCase wrote:

"I'll go run the XOR opcode", so in other words I'm right.

The CPU has the ability to recognise an XOR opcode, and every other opcode it uses, and if part of an instruction isn't an opcode it is data. Therefore a CPU knows, after the 'decode' process, what is an opcode and what is an operand, correct? This requires just a yes or no answer.

The problem is that your data may just happen to match an op-code. Op-codes are restricted in number, but data can take any value. Thus, if you recognize an XOR op-code in memory, it could be an op-code, but it might not.

You could also check whether the memory is marked as executable, in which case you could probably confirm that something is indeed an op-code. Now what? That doesn't actually tell you what it's doing with data, who the data belongs to, etc.

Hans

[HenryCase]

yakumo9275 wrote:
Yes memory protection is so easy to add to amiga os

I never said it was easy, or even desirable, but I do think it can be done. What's wrong with wanting to discuss that?

Anyway the rest of your post before you went doolally was useful, so thank you.

[HenryCase]

@Hans
I'll reply to you soon, just off for some food.

@A6000

A6000 wrote:
When the CPU reads a memory location or a block of memory, it fetches something like this:-
1011001 11001100 11101010 00110110 01101111 00001110

the only way to interpret this "data" is to know what the CPU is expecting.

I think I have a way around this...

A6000 wrote:
So the only way for the operating system to know if a byte contains an opcode or data is to emulate the cpu in software and follow the execution of the program from the start, which will be very slow, it cannot simply read a byte and know whether it has fetched an opcode or data.

Bingo. CPU emulation is part of my plan. Yes it is too slow to use for running programs in real time, but it can be used to construct a 'map' of the program. This 'map' would only need to be created once, but would then be used by the operating system to help guide the program execution at key points.

[HenryCase]

@Hans

Hans wrote:
The problem is that your data may just happen to match an op-code. Op-codes are restricted in number, but data can take any value. Thus, if you recognize an XOR op-code in memory, it could be an op-code, but it might not.

Going back to something yakumo9275 mentioned in his last post:
"XOR is encoded with 5 bits, so after the 'decode' process, the 5bit XOR opcode is out, the processor is left with 26bits.. only they are not data, its still the same opcode. (all ppc instructions are 32bits)."

Do 68k processors have the same 'fixed length op-code' trait? If so, couldn't you read the first how ever many bits (16? 32?) after the program counter in the CPU incremented as the opcode?

Hans wrote:
You could also check whether the memory is marked as executable, in which case you could probably confirm that something is indeed an op-code.

That sounds promising.

Hans wrote:
Now what? That doesn't actually tell you what it's doing with data, who the data belongs to, etc.

Don't opcodes always have the same operand requirements ('x' many operand bits for one opcode format, 'y' many operand bits for another format)? If so, couldn't you use this format to determine what the data used by an operand represented in non-binary form?

[Hans_]

HenryCase wrote:

Hans wrote:
Now what? That doesn't actually tell you what it's doing with data, who the data belongs to, etc.

Don't opcodes always have the same operand requirements ('x' many operand bits for one opcode format, 'y' many operand bits for another format)? If so, couldn't you use this format to determine what the data used by an operand represented in non-binary form?

No. You could perform an XOR on any type of data, from text, through to graphics, and even pointers.

Hans

[HenryCase]

@Hans_
Thanks for the quick reply.

Hans_ wrote:
No. You could perform an XOR on any type of data, from text, through to graphics, and even pointers.

Sorry, I worded my question badly, I meant more along the lines of the length of the data. So for instance certain addition instructions would have two blocks of data (i.e. the two values to be added together). Is there a way of determining the data length in terms of these blocks?

HenryCase wrote:
The CPU has the ability to recognise an XOR opcode, and every other opcode it uses, and if part of an instruction isn't an opcode it is data. Therefore a CPU knows, after the 'decode' process, what is an opcode and what is an operand, correct? This requires just a yes or no answer.

No. Here's an example to make this very straightforward. Assume a mythical computer with an instruction set containing ADD, LOAD, and STORE. ADD sums two registers and puts its output in the first register. We assign these instructions numbers, 0 through 3. Our computer has only two registers, which we'll number 0 and 1. Our computer uses 4 bit 'bytes' (to keep the math simple for me) so we have possible values in each 'byte' of 0 through 15, or 0xF. Now, let's say I have 20 'bytes' of memory starting at 0x00. OK? This is actually a fairly reasonable computer to use as an example here. It's missing branching and comparisons, but they will fit within the model, but they're not needed for this example.

Suppose I want to write a program to add three numbers (3, 5, and 2) without carry, it might look something like this, assuming the three numbers are in the first 3 'bytes' of memory already and I want to output to fourth 'byte':

LOAD reg0, 0x0
LOAD reg1, 0x1
ADD
LOAD reg1, 0x2
ADD
STORE reg1, 0x3

now this assembles to:
0x10011101120313

that's our actual binary executable for our mythical computer there.

Now, suppose I write a program (for a version of this computer with more memory and some I/O capability) which stores a user password. This will be done by using two four-bit 'bytes' per character, so we'll use ASCII. Only we're going to use ROT-n to encode the passwords so they can't be as easily read. Arbitrarily, the program has selected -21 for the offset, n, so each letter has 21 subtracted from it's ASCII value before storage. So if the user enters password "#l|l}n~" we get 0x10011101120313 as the encoded password.

Yes, that's the same binary code as the program. So which is which? Which one will the program execute? Both, and with identical results either way.

Real software will unfortunately have runs of bytes where there is a mix of program code and data. So you can't tell what's code, what's data, and what might be a special kind of data called a pointer.

The _only_ way to implement memory protection for a system where programs read and write shared memory is to run each program in a virtual machine where it is the only application running, like Apple did with the Classic environment in OS X, or to write each and every program that will run on the system to inform the operating system of its intention to use shared memory. Amiga software wasn't written that way, so that options doesn't work.

[SamuraiCrow]

@HenryCase

In a 68k instruction set (as well as the x86), there are variable widths for instructions to have.  This would make PowerPC much easier since all of its instructions are the same length.