Please paste small asm-listing of:

You don't need another syntax. You just need to make your assembler take the "#43->R0" syntax, split the constant up into bytes, and spit out the four-instruction sequence.

No one is going to be enthusiastic about punching your code into an assembler and posting the results when you can do that for yourself.

If you don't have a working Pi on which to run as, you can find and install a cross-assembler (such as CodeSourcery) on a PC.

--
roger ivie 
rivie@ridgenet.net

This is posted to comp.sys.arm where some COLLABORATORS may have their assembler open. Others have already pasted 8 line listings.

It's like asking someone for the time. Buy your own watch!!

Besides if I've suceeded in explaining my idea, you'd know that the whole idea is to avoid opening another canOworms: assembler and just use the existing shell.

I don't have an assembler open, or am anywhere near a Pi at the moment. But here's a simple way to get an interactive ARM assembler:

Download the RISC OS SD card image for the Pi and write it to a spare SD card Boot it on your Pi Press Ctrl-F12 Type:

*BASIC P%=&9000

Then you have an interactive assembler - just precede each line with [ and it'll be assembled on the fly with code listing printed as you go. A random code example:

[.label [MOV r0,#34 [ADD r0,r0,r0,LSL#3 [MOV pc,r14

(if you have to backtrack, adjust the value of P%, eg P%=&9004 to begin assembling on top of the ADD instruction)

And you can call this code with PRINT USR&9000 (which prints the value returned in r0).

You probably want to actually write your assembler in a file for anything complex, but it's good for testing out simple things.

I'm afraid you're going to have to learn the opcodes to get anywhere, but how hard can it be?

Theo

Thanks Roger. In re-reading your post, we see a demonstation of opening-a-can-O-worms. Which I deliberately wanted to avoid; but failed to -- partly. Noticing that my PC:slackware has `as` installed, I checked rPi, and found it has too. So:

1=check that slak:as is easy to use; 2=check that rPi:as is easy to use [my one rPi gives gcc-errors!!]

So I got the byte-sting-LISTINGS for: #N -> rR rR -> memoryM branch HERE

But the canOwrms opened when I noticed that the byteString for `#N -> rR` can't be simply for odd-numbered R. It's been OPTIMISED!!

My ideas was to build on the execellent CambUni tutorial, but allow users who don't need/want to know about asm, hex, registers, to just `dd` the bytes into a spare SD using the shell.

Collaboration is about not repeating work that others have done. OTOH education is about repeating what others have done.

I have no idea what you mean by "it's been OPTIMIZED!"

1 .text 2 3 0000 AD00A0E3 mov r0,#0xad 4 0004 DE0C80E3 orr r0,r0,#0xde00 5 0008 EF0880E3 orr r0,r0,#0xef0000 6 000c BE0480E3 orr r0,r0,#0xbe000000 7 0010 30008FE5 str r0,memoryM 8 9 0014 AD10A0E3 mov r1,#0xad 10 0018 DE1C81E3 orr r1,r1,#0xde00 11 001c EF1881E3 orr r1,r1,#0xef0000 12 0020 BE1481E3 orr r1,r1,#0xbe000000 13 0024 1C108FE5 str r1,memoryM 14 15 0028 00009FE5 ldr r0,[pc,#0] 16 002c 000000EA b .+8 17 0030 EFBEADDE .long 0xdeadbeef 18 0034 0C008FE5 str r0,memoryM 19 20 0038 00109FE5 ldr r1,[pc,#0] 21 003c 000000EA b .+8 22 0040 EFBEADDE .long 0xdeadbeef 23 0044 04100FE5 str r1,memoryM 24 25 memoryM: 26 0048 00000000 .long 0 27 28 .end

I see nothing different about the r0 and r1 sequences that doesn't look like a likely difference due to changes in A) the register number and B) the distance to memoryM.

I don't understand how you expect folks to work at this level without needing/wanting to know about asm, hex, and registers. Typically, if you don't need/want to know about asm and registers you work at the C level.

Education is about pounding things into your own stupid head.

--
roger ivie 
rivie@ridgenet.net

WoW! That seems quite amazing. The old RISC OS? Actually I found that my Slackware installation does something-like and gives a listing.

The whole point is to have a system to debug rPi with only about 6 pseudo-instructions:-- #N -> rR rR -> memoryM rR-#N -> rS I'm afraid you're going to have to learn the opcodes to get anywhere,

No. If I need to learn the opcodes, my project has failed. If the normal way is to fill-in a form and send it to a government department, and I claim a novel method of just reaching-out-and-touching it, and I still have to go via the government department, then I've failed.

From the various listings which I made, it seems that for r0, r2, r4 .. you can just slot-the-#N-byte-into the 4-byte-template for: #N -> rR. Apparently for optimising reasons, the ODD-number regs don't do that. But that's OK for my purpose.

Apparently I have'nt completely failed to explain how this will allow rPi to users debug their hardware with only the existing shell; by using the

6 simple pseudo-instructions, because your suggestion goes well towards that.

...

But if you learn the opcodes, you can explain what you mean in a way that doesn't sound like gibberish.

No matter what you think, ARM assemblers don't optimize.

--
roger ivie 
rivie@ridgenet.net

Perhaps you can give some examples of the "byte-code" you have created and explain which bits you have altered to set which registers.

Because there are only a couple of instructions that will only accept even-numbered registers and I suspect you aren't using those particular codes.

I can't see how you plan to do that. It sounds like you are trying to introduce an obfuscation layer.

Please stop feeding the troll, you are now polluting two newsgroups.

Follow-ups to csrpi as at least there is noise there to lose this amongst.

---druck

ARM GAS w7.s page 1

1 /* mov r2,#0x123456 = invalid constant (123456) after fixup */ 2 0000 3F28A0E3 mov r2,#0x3F0000 codes.

It's difficult to see how the simplicity isn't obvious:

1.CPU starts & runs from bytes in specific mem-locations; 2.the is given by the CambUniTutorial; 3.`dd` will write the bytes which are associated with the machine-instructions, to the file.

Is it not true that 'byte 28 A0 E3' does: byte -> r2 forAll 'byte'?

And 'byte R8 A0 E3' does: byte -> rR for even numbered R.

And I only need one register.

On 2014-01-01, Unknown wrote: ...

...

It is, indeed, *not* true.

As *your own* listings show, it does 0x00byte0000 -> rR. It'll also work for odd R.

And here is where you get in trouble because you don't understand the ARM instruction set. In addition to supplying a byte constant, the instruction encodes how far to shift it. For this instruction, the assembler has found another way to express the byte and has used the alternate expression 0xbc == 0x2f

Exactly.

Also, another thing you (OP) don't seem to have realised is that *all* ARM instructions are exactly 32 bits wide, unlike other instructions sets where they could be 8, 16, 24, 32 etc bits wide. It's one of the things that make it so efficient.

This means that there is no way to just say "Load Rn with

32-bit-immediate-value", other than as a shifted 8-bit value. That is why the LDR "Load Rn from address-pointed-to-by-Rs+/-8-bit(with shift)optional-offset" instruction exists.

Exactly: Arm seems to have been designed as rock bottom cost hardware with no microcode.

Compared with a CISC architecture this means that certain things have to be done in different ways.

the 'load from offset of program counter' is one such way

--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
lead are elected by the least capable of producing, and where the  
members of society least likely to sustain themselves or succeed, are  
rewarded with goods and services paid for by the confiscated wealth of a  
diminishing number of producers.

Cost is only one parameter that a RISC design attempts to optimize. Performance and power are the others.

--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

In the case of ARM the ex ARM people I have spoken to are adamant that cost was the overriding concern at the time: that it resulted in very low power consumption was actually a feature that happened as a serendipitous accident.

AS far as performance goes, that of course was always a design target, if it could be arranged via simple chip architectures.

--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
lead are elected by the least capable of producing, and where the  
members of society least likely to sustain themselves or succeed, are  
rewarded with goods and services paid for by the confiscated wealth of a  
diminishing number of producers.

No, I wanted to eliminate the need for assembling, by having

4 instr types which can be directly written [by shell's `dd`] to the starts/resets vector adr.

But my basic assumption is WRONG! rPi is not like a 8-bit-uProc; it's a 'PC', which starts/resets from the code in the .

Which you can't access/change. If it doesn't run the code correctly, there's nothing to debug.

OTOH I'm wondering what /boot/bootcode.bin is: which has all zeroes up to 200: e0 00 00 6d Is that a jump instruction?

I got no reply to my query 'what's ARM/rPi's reset adr'. Aren't there any hardware people here?

What's the point of collaboration, if each one must search for the same trivial details? Are they training engineers are clerks? ====== ipNews.Send *

---snip---

No one spotted how ABSURD my idea was!

SD is not a memory-chip, which you can address-directly via a machine instruction. it's a complete file-system which FIRST needs the whole OS to be running before it can be accessed. So how could it possibly be used for code to debug at the lowest level: before the OS is running ?!

That's why I didn't want to look into the trivial details. First the basic idea must be valid.

--
I was misled/fooled by the CambUni Tutorials. 
Altho' they do manipulate bytes to/from specific registers, 
they do it via a fully functional OS.  
And can't be used for debugging, 'cos they won't work 
unless the system/OS is fully functional.

It's worse than that.

The Raspberry Pi is fundamentally a GPU with an ARM sidecar; the primary processor in the system is the GPU. When the system powers on, the GPU reads bootcode.bin and start.elf, using those to set up the hardware and load the kernel. They are not ARM code, they are code executed by the GPU.

Don't know. The GPU instruction set is proprietary.

We've shown you where to get documentation. The documentation talks about what happens at reset. The processor is an ARM1176JZFS. Section 2.12 of the manual for that processor talks about exceptions. Section 2.12.5 specifically talks about reset.

Engineers typically want to understand the system they are working with. That means reading and understanding the documentation.

You seem to be only interested in being a clerk; having a fixed recipe that a knowledgeable person handed you which just works when you wave the dead chicken the right way.

--
roger ivie 
rivie@ridgenet.net

In the beginning was the GPU. And the GPU was proprietary, and without publically available documents. And the power supply said "Let there be reset!" and the GPU awoke.

And lo, the GPU reached out to the SD card and read bootcode.bin, and saw that it was good. And so bootcode.bin was executed.

And bootcode.bin reached out to the SD card and found start.elf, and saw that it was good. And so start.elf was executed.

And the start.elf configured the system. RAM was divided between the GPU and the ARM.

And the start.elf loaded the kernel into the ARM side of the RAM. And the ARM was reset.

And the reset most likely proceeded in the manner described in the technical reference manual for the ARM1176JZFS processor.

--
roger ivie 
rivie@ridgenet.net