Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics

On 26 Jun, 11:14, "Ulf Samuelsson" <u...@xxxxxxxxxxxxx> wrote:
<wilco.dijks...@xxxxxxxxxxxx> skrev i meddelandetnews:1182838751.331770.190430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx





On 25 Jun, 17:12, "Ulf Samuelsson" <u...@xxxxxxxxxxxxx> wrote:
Put simply, the question is "Can you read data from code memory at a
random address?".

Wilco

Any Harvard architecture can read data into registers using the immediate
addressing mode.

getdata: execute label[r0:d]
ret

label:
label0: ld r0,#0
label1: ld r0,#1
label2: ld r0,#2
label3: ld r0,#3
label4: ld r0,#4
label5: ld r0,#5
label6: ld r0,#6

Should work on a Harvard architecture without going to
a "modified Harvard" so the question is irrelevant to determine
Harvard/No Harvard.

So how does this read the *data* contained in the code memory? I'd
like to read the bitpatterns of the instructions, not execute them.

Wilco

The data is embedded inside the instruction, and gets loaded
into R0, using immediate addressing mode.

That still doesn't data. If I have 1KByte of data, can you encode it
in 1KB of code? If the answer is no, then they are not equivalent.

I bet there is no Harvard architecture, which does not allow use of
constants embedded in instructions, so if you accept
that, then you also accept that there is a path from the
instruction bus to the internal registers without having
to connect the databus.

Sure this path always exists for immediates. But this path can't read
any random byte from the instruction memory, it can only be used for
immediates. You need special instructions like MOVC to read actual
data from a random address. The key "feature" of the original Harvards
was that they could not treat instructions as data, unlike Von
Neumann.

What you "like" is really irrelevant for the discussion
on whether moving from instruction bus to ALU is
deviating from original harvard or not.

If the microarchitecture connects the instruction memory
to the ALU using an internal mux in the CPU core it is original harvard.
If it connect the databus to the instruction memory to
fetch data, it isn't.

I don't see why you'd want to separate them based on how the buses are
implemented, this is a micro architecture detail. There are various
options, including a mux inside the core, 2 separate buses with a mux
to unify them or an independent bus used only for code->data. Each of
these options behaves the same from a programmer's perspective, so
there is no obvious way to differentiate them.

Wilco

.

Relevant Pages

  • [PATCH] x86-64 kprobes: handle %RIP-relative addressing mode
    ... The existing x86-64 kprobes implementation doesn't cope with the ... an instruction overwritten by a breakpoint. ... instruction that uses the %RIP-relative data addressing mode, ... This patch fixes the problem by recognizing the %RIP-relative addressing ...
    (Linux-Kernel)
  • Re: What the?
    ... the relative efficiency of these operations; this mythology is largely based on the PDP-11 ... instruction set which had a pre-increment and post-decrement addressing mode built into ... increment and decrement could be built into the instruction address bits (in fact, ...
    (microsoft.public.vc.mfc)
  • Re: "Complete exercise" of x86 example?
    ... bit instruction set (excluding 8086-specific and intel-specific quirks ... such as POP CS and AAD/AAM with custom operand). ... something, or screw up a lesser-known addressing mode, or some other ... A complete set of all possible instruction variants and addressing ...
    (comp.lang.asm.x86)
  • Re: What the?
    ... instruction set which had a pre-increment and post-decrement addressing mode built into ... increment and decrement could be built into the instruction address bits (in fact, ... For reference, here are canonical ...
    (microsoft.public.vc.mfc)
Loading