How to move AROS forward

[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.

[HenryCase]

@pkillo
Thanks for your examples, I enjoyed following them. In your imaginary computer how does the CPU know when to increase the Program Counter?

@SamuraiCrow
I see. Well a fixed instruction width would have made our lives easier, but seeing as the vast majority of Amiga software is compiled for 68k CPUs let's see what we can do with that.

[A6000]

Variable length instructions are no problem, they are fully documented, if the CPU expects the next byte to be an opcode, that opcode will be decoded and reveal if the following byte is also an opcode.
I think 68k instructions range from 1 to 16 bytes including operands where applicable.

[SamuraiCrow]

Being designed for a 16-bit bus, the 68000 has only 16-bit multiples in its instruction set.  That makes all of the opcodes either 16,32,48 or 64-bit sizes.  No 8-bit opcodes, in fact, word misalignment will cause a lock up on 68000 series processors.

[A6000]

HenryCase wrote:
@pkillo
Thanks for your examples, I enjoyed following them. In your imaginary computer how does the CPU know when to increase the Program Counter?

The program counter is automatically incremented after every instruction execution.

One fly in the ointment for your idea of tracing program execution is that data may not be static, it might be input in real time to change program flow, or data might come from another part of the program which only executes if certain conditions are met, dependant on real world input, or data may come from another program entirely.
You may need to log all input data just in case the program you are tracing needs the data that came in during the trace time. it's all getting quite complicated.
You may not know the data found at the memory location is invalid.

[HenryCase]

A6000 wrote:
One fly in the ointment for your idea of tracing program execution is that data may not be static, it might be input in real time to change program flow, or data might come from another part of the program which only executes if certain conditions are met, dependant on real world input, or data may come from another program entirely.
You may need to log all input data just in case the program you are tracing needs the data that came in during the trace time. it's all getting quite complicated.
You may not know the data found at the memory location is invalid.

A6000, this is the one issue I am trying to resolve at the moment. I'd much rather use some sort of feedback loop system that matches input, output and possibly the emulated CPU state, and analyse this information as a whole, rather than keep track of all inputs and work out the progression as a sequence.

I won't ask for 'any ideas' on this matter as I know I'll just get the usual 'it can't be done' stuff, and I'd much rather have a better explanation than that.

[A6000]

Just checked, 68k instructions range from 2 to 10 bytes, though I vaguely recall that instructions relating to co-processors such as the FPU may use up to 16 bytes.

[A6000]

HenryCase wrote:
I won't ask for 'any ideas' on this matter as I know I'll just get the usual 'it can't be done' stuff, and I'd much rather have a better explanation than that.

I don't know enough about programming to say it is impossible, but I can see it won't be easy.

Sandboxes have been mentioned several times, maybe this would be easier.
And just how important is memory protection anyway? we managed without it for a quarter of a century.

[itix]

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.

It is not so simple. You must actually execute code to find out what is actually data and what is an opcode. It is not big problem, UAE does that when translating memory accesses to local memory space.

But this is not going to help you at all. Just like UAE, 68k processor (virtual or real one) does not care or know about operating systems. It is very difficult to find out when program is calling OpenWindow() and it is even more difficult to find out when that particular function returns.

You should try to disassemble some Amiga program and try to figure out where it is calling OpenWindow()... or figure out memory location where it stores struct Window.

[HenryCase]

@A6000 and @SamuraiCrow

Thank you both for the 68k opcode information. My next question is linked to what you both said last. If 68k opcodes are 2-10 bytes in length, and one opcode can be directly followed by another opcode (i.e. no data in between) how does the instruction code tell the CPU to expect an opcode rather than operand data? Is there an opcode 'flag' instruction, or is it purely determined by the current opcode in use (and its operand needs)?

[HenryCase]

itix wrote:
You should try to disassemble some Amiga program and try to figure out where it is calling OpenWindow()... or figure out memory location where it stores struct Window.

Sounds like a good challenge.

[Piru]

@HenryCase

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.

No, you can't do that. It's not possible to somehow trigger the program to take all possible codepaths. Thus your map will always be incomplete and thus totally useless (and I'm not even going into how you would automagically be able to fix the programs, which you can't either).

As soon as the program takes codepath it didn't while mapping your concept fails.

[HenryCase]

@Piru
As I said before, I am currently looking of ways around this issue. The code map may end up being in a more high level modular structure. Maybe also we keep a record of the code paths we have taken before, and if a new one arises we track its performance, adding to our code map. These ideas are only rough sketches for now, I only realised through this thread that I'd have to deal with pointer issues when retrofitting Amiga operating systems and apps with MP, so forgive me for not going into more detail.

@all
Whilst I carry on sketching out how to track the performance of Amiga programs, I'd like to take the discussion about MP on a simpler route. Seeing as the whole idea of AROS being OS 3.1 compatible is on a source code level (apart from the plans for binary compatibility on the 68k port), let's start discussing how to graft full MP into AROS through program compilers. Would there be any way to make AllocMem (and all other AROS functions) behave as they should without using pointers (maybe using some new 'port' system instead that AROS could flag and control)?

[A6000]

HenryCase wrote:
@A6000 and @SamuraiCrow

If 68k opcodes are 2-10 bytes in length, and one opcode can be directly followed by another opcode (i.e. no data in between) how does the instruction code tell the CPU to expect an opcode rather than operand data? Is there an opcode 'flag' instruction, or is it purely determined by the current opcode in use (and its operand needs)?

When the processor completes an instruction it increments the program counter and fetches the next instruction, the word (2 bytes) returned will specify the instruction, if the instruction requires operands the next 2,4 or 8 bytes will tell the CPU where to get it's operands from. these additional bytes will be immediate data, registers or memory locations, source and destination.

HenryCase wrote:
@pkillo
Thanks for your examples, I enjoyed following them. In your imaginary computer how does the CPU know when to increase the Program Counter?

Each instruction has the 'side effect' of incrementing the PC by the size of the instruction (in my example 1 byte) and the total size of the operands (0 or 2 bytes in the example).

btw, this program 'tracing' is probably not impossible; it's just that you will generate a geometrically increasing pile of what I'll call garbage data alongside your program's actual data. I call it garbage data because it's not useful for producing the results of the programs run, but only to 'fix' features of the programs being run. what you're seeing as needed for it is the tip of a gigantic iceberg. It would be cheaper in the long run to write all new software or do without memory protection. Much cheaper.

[Piru]

@HenryCase

let's start discussing how to graft full MP into AROS through program compilers.

MP is not the task of the compiler.

Would there be any way to make AllocMem (and all other AROS functions) behave as they should without using pointers (maybe using some new 'port' system instead that AROS could flag and control)?

Even if you could, the actual poking can be in the code, not the OS itself. The code needs to be rewritten, compiler can't possibly know how to do that for you.