Roger, you have two very religious people here laughing. It's very excellently written. Is that original? (I had to explain some of the technical terms to my wife, but she liked the piece, too.)
Thanks.
-- Robert Riches spamtrap42@jacob21819.net (Yes, that is one of my email addresses.)
Yes. Original and off-the-cuff.
-- roger ivie rivie@ridgenet.net
No. They don't.
The Cambridge Uni code examples are loaded from the SD card into ARM RAM by the GPU code (something like a PC's "BIOS"). Then the ARM is started and the code runs. The code is effectively the "OS".
You can include debug statements in your code - from simple things like a blinking LED sequence, to driving a small LCD character display, to dumping messages on the screen (once you have written code to initialise it and display text - not too hard).
If you want to read/write to the SD card you will need to write a driver for it. The SD card protocol (can't imagine how you thought you could you'd not need that) is available on line and the interface locations are given in a PDF that has been released by the Foundation.
Roger Ivie wrote
And let there be light. Thanks for the above. I have copied it to form the opening paragraph of pi notes.
John
Foot it featly here and there And, sweet sprites, the burden bear. WS
---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. === You can debug a person: by checking if he's breathing, to know it he's dead. The CambUniv take a live person, and asks him if he's breathing. When the subject answers "no" [because it's being interogated by a fully operational OS] they declare that logically he's 'dead'. == Nigerian 4-1 scams work by distracting your attention. CambUniv unintionally distracted my intention by going-off about binary arithmetic [most annoying]. That's my excuse for being led to absurd conclusions.
Ask yourself : how is it possible to boot an OS from a file system?
He doesn't ask himself anything other than how can I keep trolling these fools on the newsgroups.
=== No! I wantED a listing of the bytes; whithout looking into asm; to make a VM, which would eg: #4 -> r0 r0 -> memoryM r1 r0` would need to be achieved by a block of bytes, and `#BC -> r0` is expected to differ by only '04 BC'.
What I overlooked is that this is NOT a uProc, where I can put bytes at the reset vector to debug at the very lowest level.
ABSURDLY, I was thinking of 'shell: dd - ing' the P-code to . But that's like saying "you can test if a person is alive; by noticing if they are breathing; so ask that bloke if he's breathing".
An assembler is a tool that does that for you - tell it your assembly language code and it will give you the machine code.
Running an assembler on your own computer is significantly more efficient than posting your code on a newsgroup and having someone else feed it through theirs.
Of course you need valid assembly language as an input which people have attempted to help you with, but you're obviously too much of a moron (or troll) to read any of that.
OMG, it's next year already!!
There are 2 separate issues:
English is optimised/irregular by eg. 'a' becomes 'an' before a vowel.
A quick look at your listing below seems to be regular. Perhaps: Byte:Operand Nyble:Reg 20Bits:0A0E3 is the direct translation of Operand -> Reg:r for all byteOperands and all registers?
orr
orr
Hex & registers are universal. Like mathematics. The particular asm, is just another syntax. I don't want to know ANOTHER syntax.
Perhaps you've heard of Pseudo-code running on virtual-machines, which was popular in the 70s ? Shells are a bit like that: abstracting-out the in-essential.
Yeah, well if you would bother to *read* the rest of the thread, you just might find an explanation for the encoding difference.
Once again, I urge you to learn about the processor you're trying to program.
-- roger ivie rivie@ridgenet.net
On 2014-01-31, Unknown wrote: [[snippage]]
Ok, let me try it this way:
It is very odd that you sit there and complain that folks are not willing to collaborate with you when
*you* refuse to collaborate with the folks who wrote the fine manuals that have been pointed out to you several times.-- roger ivie rivie@ridgenet.net
Does that explain your previous question: "what do I MEAN by
Shouldn't that be: ByteOperand (RegNo shl 4) a0 e3 ?
I wantED to make a stack-based VirtualMachine, so 1 or 2 regs would suffice.
Why not look at someone elses?
ghostscript and gforth are available.
-- For a good time: install ntp
No! If you're a student, you may want to also 'learn about' the physics of the underlying semiconductors. But after you've done a dozen languages, you don't want to KNOW the irrelevant peculiar details.
You want to see the BIG picture. Like a better explanation of what I meant by "optimised": IF (NextInstruction=SpredJamOnToast) AND (InHand(Teaspoon)=TRUE) THEN JamToToast(Teaspoon) END;
So it seems that the [one that I used] ARM compiler, doesn't just do a one-to-one mapping from symbolic to bytes. But I'm not particularly bothered. And yes, the Camb Univ tut material needed to assume hex..etc. knowledge. But IMO it was inappropriate to introduce it "while driving".
The tut came accross as an unplanned, too enthusiatic, ad-lib thing. Which by it's noise, misled me into thinking I could just 'run the bytes' from the start vector-adr, like we did with the old 8-bit uProcs.
If you want a simple 8-bit processor, get one.
The ARM is not at all like a simple 8-bit processor, and all your wishing is not going to make it one.
The days of simple, deterministic, sequential execution of instructions are gone. Caches, multiple-issue, out-of-order execution are the standard fare today.
I love simple 8-bit machines, too, so I use one for my recreation. They are readily available (still!) on eBay, for example.
-- -michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
If you're trying to *build* a VM, the instruction set of the machine on which you're trying to run the VM is *not* an irrelevent peculiar detail.
It is *not* an optimization! The assembler is *still* just doing a one-to-one mapping from symbolic to bytes.
There are several ways that many constants can be represented in an ARM instruction. There is no particular reason for the assembler to choose one over the other. *Same* instruction, different encoding of the constant. Same *number* of instructions, different encoding of the constant.
*Nothing* is being optimized.-- roger ivie rivie@ridgenet.net
On Fri, 07 Feb 2014 02:16:26 -0600, Michael J. Mahon declaimed the following:
Heh, I just went through my parts box... I still have the Intel sample kit (it was $20 in my college days).
1 8080A 5 8212 buffers 8 2102 static RAM 1 8224 clock generator if memory doesn't fail 4 1702 UV EPROM reference manualand I'd added a UART, 20-key decoder, 8228 system controller (replaces most of the 8212s), 2-digit 7-segment LED display driver, and an S-100 wirewrap card {My college digital electronics course had intended to build a working system, so many of us bought the sample box}
A really nice, simple, instruction set processor (especially in Octal, as many instructions were 2bit opcode, 3-bit source, 3-bit destination -- I once spent a day writing a definition file for Xerox Sigma-6 Meta-Symbol that would generate absolute addressed 8080 object files). Problem -- it needed a ton of chips to interface to memory (the data bus and half the address bus were shared, so one had to latch the address using 8212s, then use another set of 8212 for the in/out data directions -- the 8228 managed all of that [yes, the support chip was nearly bigger than the main processor])
[for the OP] Practically all RISC processors end up needing very smart /assembler/ languages even -- as they tend to re-order instructions based on decode&execute time (so a register-register add may be moved to /after/ an instruction the retrieves a value from memory, as the memory fetch will still be ongoing when the r-r instruction has completed)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.