FindFirstIn

[David Brown]

No, you load p into an A register, in other to fetch the value of *p.

You /might/ load p into an A register, in order to load *p into an A
register (the same one, or a different one). I didn't bother with that
detail - especially as p might already be in a register if it is a local
variable.

But is
that result itself also put into an A register, or a D register?

Since you will use it as an address, putting it into an A register is
obvious.

Assuming you are going to use this pointer value you are constructing, the
*p value is loaded into an A register too. And assuming the hardware can't
directly take care of i*n+j, this arithmetic now needs to be performed. But
while you can add into an A register, you can't multiply using them, so
that
part is done in D registers.

But if you are only interested in constructing a pointer value to be used
later (ie. treating it as data), then *p can be loaded into a D register.

Wouldn't it be have been much simpler though if there wasn't the
distinction
between A and D types of register?

You seem determined to make this sound difficult. Have you ever
actually /used/ an m68k processor, and programmed it in assembly or
looked at the output of a C compiler? It really is very easy in
practice - there are seldom occasions when you have to make a choice of
A or D registers and where the choice also makes a difference.

Suppose you have an 64-bit 'double' value, and need to compare it with
another. If you're using x64, would it be loaded into R0 (rax), or into the
FPU?

If that requires a bit of consideration, does that mean the 'program' is
screwed up?

No, it means the x86-64 architecture is screwed up. It is not as badly
screwed up as the original x86, but it is still a mess - especially
compared to the m68k.

Logic instructions can make sense, if for example your data is 4-byte
aligned and you want to make use of those two lower bits of a pointer
which are otherwise
zero.

This is something you /very/ rarely want to do. And if you do mess
about with the lower two bits of a 4-byte aligned pointer as something
other than address bits, you are using it as data rather than a pointer,
and will typically put it into a D register. But IIRC you are also able
to do AND operations directly on an A register, so you could use the A
register if you wanted.

But my point of view is for generating automatic code (for a compiler for
example). Having to constantly think about A or D or either is a
distraction.

I don't disagree that the A and D split is a little less orthogonal than
the register sets you get in architectures like the PPC or ARM. I just
disagree that it is a problem, and I totally disagree with the bizarre
idea that it is less orthogonal than the x86.

 

[David Brown]

Them's fightin' words. Data General's Nova? (But maybe I'm forgetting
all the odd bits).

<snip>

I guess I meant that the m68k was the most orthogonal popular mainstream
microcomputer cpu until RISC designs became popular and mainstream.

By "popular and mainstream", I mean something that turned up in personal
computers of some sort, or embedded systems, rather than in mainframes
and minicomputers. I freely admit that that is a subjective definition
tuned towards "proving" my point.

 

[David Brown]

As one who moved from PDP11 to 68K, I'd say the PDP11 held that crown.
When I moved to 68K, I thought of it as a natural extension to PDP11. My
first encounter with the 8086 architecture was one of those WTF moments

I never used the PDP11, but I have lots of experience with the msp430
whose ISA was apparently based on, or inspired by, the PDP11. And
certainly the msp430 has a very orthogonal instruction set - more so
than the m68k.

 

[BartC]

On 25/05/14 17:49, BartC wrote:

Since you will use it as an address, putting it into an A register is
obvious.

(I thought I made it clear, with my three examples of what (*p+i*n+j) might
be used for, of which only one was going to be immediately used as an actual
address, that that is not so obvious.

But Keith is calling time on this sub-thread because it's going off-topic.)