ASM programming is FASCINATING!

[MK14]

We seem to have lost the OP a while ago. More specifically, we lost him right after his original post. Maybe the fascination didn't last. 

I noticed this as well, a long while ago. But decided, the thread is of general interest, and seems to be a fun and educational experience. I'm pleased with the information in it, and have enjoyed participating and reading it.
We were at least a bit off-topic as well. (Opinion dependent!).
So, if they had sticked around, it may have taken a completely different course.

I suspect, in a number of cases, you get the following:
[I'm really revving to go, and want to do assembly language programming, it must/will be great fun]
..
>>>Tries their first assembly program, 8 lines long, takes 38 minutes, to get rid of 5 assembly errors, then runs it and it crashes for no apparent reason.
..
[Gives up and moves on to something else]

[KL27x]

At least the title of the thread is appropo. I wonder how long the active oscope thread on the forum will be "what scope for a woman passionate about electronics."

Everytime I see that thread, I imagine an oscilloscope that is strong enough for a man, but is purple and vibrates and discreetly slips into a purse.

[T3sl4co1l]

True, but "modern processor" != "embedded MCU", any more than all black birds are crows.

I remember seeing a C compiler get around the limitations of an instruction set by building a subroutine on the stack, and then execute it.

Fascinating, compiled ROP?

Or was the stack somehow executable? (Is this not a ROM/Harvard machine as context would suggest?)

A note about Harvard architecture: it won, but really, both (+ Von Neumann) won: all you need is an MMU with r/w/x tagging.  If w and x are exclusive, then you have a Harvard machine at any given point in time, but you can always ask the kernel to toggle it back and write some more data.  Which can be code or data, doesn't matter until re-tagging it again.  (And perhaps this change could also trigger a cache flush or something, I don't know.)

Tim

[tggzzz]

True, but "modern processor" != "embedded MCU", any more than all black birds are crows.

I remember seeing a C compiler get around the limitations of an instruction set by building a subroutine on the stack, and then execute it.

Fascinating, compiled ROP?

Or was the stack somehow executable? (Is this not a ROM/Harvard machine as context would suggest?)

A note about Harvard architecture: it won, but really, both (+ Von Neumann) won: all you need is an MMU with r/w/x tagging.  If w and x are exclusive, then you have a Harvard machine at any given point in time, but you can always ask the kernel to toggle it back and write some more data.  Which can be code or data, doesn't matter until re-tagging it again.  (And perhaps this change could also trigger a cache flush or something, I don't know.)

Tim

It was the Whitesmiths C crosscompiler for a Z80 processor, possibly the 8080 subset. After 40 years the details are, fortunately, hazy. The long-term lessons are not!

[MK14]

If w and x are exclusive, then you have a Harvard machine at any given point in time

If the computer/processor system, has got only one single, shared memory, for instructions and data. (Von Neumann Architecture).
Then, it will still only have one shared memory bus, for instructions and data, even if you start messing with MMU tags and things.
It's the multiple, separate, non-shared memory buses. Which give Harvard Architecture, its potential performance benefits, because of having multiple bus systems, running in parallel.

You could simulate it the way you described. But, it would give little or no speed improvement, and wouldn't really change much. if you needed the extra bandwidth/performance from Harvard's extra bus system(s).

These days, the distinctions, seem to be getting blurry. So, even a Von Neumann Architecture, can achieve huge performance. E.g. Modern PCs.

[T3sl4co1l]

Right, with a single bus, you don't have the hardware advantage.  You might call such a system a "virtual Harvard architecture".

With modern machines, low level buses are very wide, and they don't care what data are being moved about; ultimately it gets into the caches it needs to, and those serve as a physical barrier again.

Tim

[MK14]

Right, with a single bus, you don't have the hardware advantage.  You might call such a system a "virtual Harvard architecture".

With modern machines, low level buses are very wide, and they don't care what data are being moved about; ultimately it gets into the caches it needs to, and those serve as a physical barrier again.

Tim

Yes, agreed.

[SiliconWizard]

Just a side thought - sorry if it has been mentioned already - but many modern CPUs (even small MCUs these days) have some form of cache, and quite often separate cache for data and instructions. So even if it has a single address space for code and data like in a typical Von Neumann architecture, from the CPU's execution unit POV, it actually has two separate buses for code and data. This has obvious performance benefits, but also has some security implications.

Likewise, quite a few processor architectures these days are fundamentally Harvard but with some additional bridges allowing them to essentially be used as Von Neumann ones from a user's POV.

[Berni]

Just a side thought - sorry if it has been mentioned already - but many modern CPUs (even small MCUs these days) have some form of cache, and quite often separate cache for data and instructions. So even if it has a single address space for code and data like in a typical Von Neumann architecture, from the CPU's execution unit POV, it actually has two separate buses for code and data. This has obvious performance benefits, but also has some security implications.

Likewise, quite a few processor architectures these days are fundamentally Harvard but with some additional bridges allowing them to essentially be used as Von Neumann ones from a user's POV.

The harward architecture is not just about having a separate instruction and data bus. Its actually about having a separate memory addressing space for instructions and data. You can have machine code at 0x100 in the program memory while 0x100 in data memory actually points to RAM instead. As a result of this a harward architecture CPU tends to have separate instructions for working with program or with data memory. Typically your usual MOV,ADD,XOR..etc instructions with addressing operands only work with data memory while there is a special instruction that loads a program memory location into a register.

This is what makes this architecture annoying for compilers since you can't just simply have a pointer to anywhere in memory. So this gives C compilers some oddities, like placing string constants into RAM so it can get a pointer to it, or introducing a special pointer type that works in program space instead.

If you go down deep enough then pretty much every CPU splits its bus into data and instruction somewhere. At some point there is a bus feeding the instruction decoder where only instruction data is fed in. It just so happens to join the main bus very early trough some latch that is only activated when an instruction comes along on the multiplexed instruction+data main bus. So an instruction cache is just simply placed in a convenient spot where only instructions flow trough so that the cache can be optimized for the access patterns that instructions use(or take hints from a branch predictor)

[T3sl4co1l]

Ironically, x86 has a Harvard architecture IO bus -- multiplexed on the same main bus, but accessed in the instruction set by two special instructions (IN and OUT, and their later extensions for word width and repeat (string) access).  And a much smaller bus, too (not even the full 16 bits presented by the CPU, though, I forget how and where this was done on the PC-XT?).

PC IO ports haven't completely gone away of course, but by many orders of magnitude of data flow, memory mapped registers and data have decidedly won out.

Tim

[T3sl4co1l]

Something of an aside, but related: an IO bus is just another set of bus strobe signals.  So the x80/x86 family has theirs.  68x doesn't (all memory mapped, AFAIK?).  Others have banked memory (and you could put IO into that just as well).  Or you could reserve entire segments of address space for various purposes.

A more general interpretation, then, could be considering any of the signals as bus enables.  The CPU asserts some combination of them; and this is now in binary rather than unary coding.  That is, the traditional multiplexed memory/IO space uses single strobes to select between them; say we have N address spaces: for N > 3, it's more efficient to use lg(N) address lines and a single strobe (and a lg(N)-->N decoder at the destinations) to do the same thing.

So we might consider an arbitrary number of common-bus address lines as bus-select lines for our various buses.

A banked memory system extends this further by using a sequence of operations with a stateful bus to make the selection.  These are already familiar to many IO devices, where for example one register's value serves as the address to the second register.

Tim

[westfw]

Ironically, x86 has a Harvard architecture IO bus

Harvard is usually about Instructions vs Data.  I don't think IO Buses count...

[KL27x]

If I ever find myself disagreeing with Tim, my default conclusion is I don't know enough to understand how he is right. 

[SiliconWizard]

The Wikipedia article more or less details what I summed up above : https://en.wikipedia.org/wiki/Harvard_architecture

These days, most CPUs are actually some form of "modified Harvard" rather than pure Von Neumann architectures.
Not that it matters much, since the original definitions applied to very simple architectures - most modern CPU architectures are much more complex in comparison.

[eti]

To the OP that's just having fun learning, I recommend the following book:

We seem to have lost the OP a while ago. More specifically, we lost him right after his original post. Maybe the fascination didn't last. 

No no, I am still browsing, I just have a real life outside forums, you know? There's only 24 hours a day, and I can't spend all of them online Besides, I bow to the superior ASM knowledge of all thread contributors; suffice to say that you guys appear to have infinitely more experience than me in this area, which is new to me for now, and I enjoy reading as and when I get 5 mins off to come here.

[MK14]

 

[eti]

We seem to have lost the OP a while ago. More specifically, we lost him right after his original post. Maybe the fascination didn't last. 

I noticed this as well, a long while ago. But decided, the thread is of general interest, and seems to be a fun and educational experience. I'm pleased with the information in it, and have enjoyed participating and reading it.
We were at least a bit off-topic as well. (Opinion dependent!).
So, if they had sticked around, it may have taken a completely different course.

I suspect, in a number of cases, you get the following:
[I'm really revving to go, and want to do assembly language programming, it must/will be great fun]
..
>>>Tries their first assembly program, 8 lines long, takes 38 minutes, to get rid of 5 assembly errors, then runs it and it crashes for no apparent reason.
..
[Gives up and moves on to something else]

I NEVER give up! I may "temporarily set-aside" an interest, no matter how fleeting my current interest in it, is, and allow my life to continue, and allow whatever I've learnt up until that point, to subconsciously absorb into my mind and digest for however many weeks, months or years, but my interest is still there. I may not be au fait with this subject, but I have returned, re-visited my ASM interest, failed a few times to grasp... but it's truly absorbing into my mind now

[eti]

?

[MK14]

We seem to have lost the OP a while ago. More specifically, we lost him right after his original post. Maybe the fascination didn't last. 

I noticed this as well, a long while ago. But decided, the thread is of general interest, and seems to be a fun and educational experience. I'm pleased with the information in it, and have enjoyed participating and reading it.
We were at least a bit off-topic as well. (Opinion dependent!).
So, if they had sticked around, it may have taken a completely different course.

I suspect, in a number of cases, you get the following:
[I'm really revving to go, and want to do assembly language programming, it must/will be great fun]
..
>>>Tries their first assembly program, 8 lines long, takes 38 minutes, to get rid of 5 assembly errors, then runs it and it crashes for no apparent reason.
..
[Gives up and moves on to something else]

I NEVER give up! I may "temporarily set-aside" an interest, no matter how fleeting my current interest in it, is, and allow my life to continue, and allow whatever I've learnt up until that point, to subconsciously absorb into my mind and digest for however many weeks, months or years, but my interest is still there. I may not be au fait with this subject, but I have returned, re-visited my ASM interest, failed a few times to grasp... but it's truly absorbing into my mind now

If you start a thread, and people take the time to answer your original question(s). It is the polite thing, to return to the thread in a timely manner, and then respond to it.

I get a bit agitated when people start a thread, then disappear, either permanently, or for very long periods of time.

[eti]

We seem to have lost the OP a while ago. More specifically, we lost him right after his original post. Maybe the fascination didn't last. 

I noticed this as well, a long while ago. But decided, the thread is of general interest, and seems to be a fun and educational experience. I'm pleased with the information in it, and have enjoyed participating and reading it.
We were at least a bit off-topic as well. (Opinion dependent!).
So, if they had sticked around, it may have taken a completely different course.

I suspect, in a number of cases, you get the following:
[I'm really revving to go, and want to do assembly language programming, it must/will be great fun]
..
>>>Tries their first assembly program, 8 lines long, takes 38 minutes, to get rid of 5 assembly errors, then runs it and it crashes for no apparent reason.
..
[Gives up and moves on to something else]

I NEVER give up! I may "temporarily set-aside" an interest, no matter how fleeting my current interest in it, is, and allow my life to continue, and allow whatever I've learnt up until that point, to subconsciously absorb into my mind and digest for however many weeks, months or years, but my interest is still there. I may not be au fait with this subject, but I have returned, re-visited my ASM interest, failed a few times to grasp... but it's truly absorbing into my mind now

If you start a thread, and people take the time to answer your original question(s). It is the polite thing, to return to the thread in a timely manner, and then respond to it.

I get a bit agitated when people start a thread, then disappear, either permanently, or for very long periods of time.

Well, here I am reporting in for duty, Sir! What is my penalty - do I get bread and water rations tonight, or will you let me off?

You do understand it has (barely) been FOUR DAYS since I started the topic? Hardly an eternity. I am sorry you feel the way you feel, see if you can find a family member to hug!

[greenpossum]

We seem to have lost the OP a while ago. More specifically, we lost him right after his original post. Maybe the fascination didn't last. 

No no, I am still browsing, I just have a real life outside forums, you know? There's only 24 hours a day, and I can't spend all of them online Besides, I bow to the superior ASM knowledge of all thread contributors; suffice to say that you guys appear to have infinitely more experience than me in this area, which is new to me for now, and I enjoy reading as and when I get 5 mins off to come here.

That's just the way EEVblog is, every discussion will eventually turn into a exposition by experts of angles far outside the scope of the original query or observation. Often educational but sometimes overwhelming. So I look at the reply count of a topic and if it's large, it's probably not worth entering. If there is a post worth reading, a targeted search will find it better.

[MK14]

Well, here I am reporting in for duty, Sir! What is my penalty - do I get bread and water rations tonight, or will you let me off?

You do understand it has (barely) been FOUR DAYS since I started the topic? Hardly an eternity. I am sorry you feel the way you feel, see if you can find a family member to hug!

I can only express the opinions of one person. Let's see what others think.

My perception was that this thread was started some 2 weeks ago. I'm amazed it was started on the 26th July.
Human perception, can make mistakes, like mine just did, sometimes.

[eti]

Well, here I am reporting in for duty, Sir! What is my penalty - do I get bread and water rations tonight, or will you let me off?

You do understand it has (barely) been FOUR DAYS since I started the topic? Hardly an eternity. I am sorry you feel the way you feel, see if you can find a family member to hug!

I can only express the opinions of one person. let's see what others think.

My perception was that this thread was started some 2 weeks ago. I'm amazed it was started on the 26th July.
Human perception, can make mistakes, like mine just did, sometimes.

It's alright, don't think any more about it, we all make mistakes my friend - it's a TOTAL non-issue to me

[Ian.M]

@Eti,
So now you've had a chance to catch up, where do you want to direct this thread to?

If anyone would like to comment or advise how best to get a true, firm grasp on ASM, I'm open to suggestions.

IMHO that's best achieved by programming in assembler with the big thick core instruction set 'bible' for your processor open beside you, though reading other people's well commented code can also help. 

However, jumping right in at the keyboard and coding freehand is counter-productive^* - that's how you make a mess of spaghetti code.  As ASM has so little structure, you must always code with clear objectives, develop well defined interfaces between modules of your program, and keep track of side effects (e.g. registers a subroutine 'smashes').   An hour designing appropriate data structures is worth ten or even a hundred hours coding.

* Early in learning a particular CPU core free coding routines small enough to grok in their entirety, then stepping through them either under a debugger or dry-running them has its place, but if you have to scroll the editor window or shuffle pages to find a branch target its getting too big to reliably comprehend.

One thing that's essential is a quick reference card that shows which registers and flags are affected by each instruction, as especially on CPUs with minimal working registers, you will find yourself testing something, doing <something else>, then attempting a conditional branch on the result of the test.  Its nice to be able to pull it off to avoid having to duplicate the code <something else>, but of course <something else> mustn't smash the flag bit(s) needed for the conditional branch.

On the subject of evil instruction sets: the baseline (12 bit) PIC core cant return from a subroutine without smashing W (its accumulator and sole working register) as it doesn't have a RETURN instruction.   It only has RETLW (Return literal in W), so any subroutine that needs to pass back a value in W has to have multiple exit points, one for each possible value!

[RJSV]

Responding here with noted differences, 6502 and
Z-80 compared:. Both types have same math, so that helps, if writing ASM code.  Now, 6502 and 6800 are termed 'memory mapped' (the registers holding active variables).
  Writing ASM with a Z-80, that CPU is termed as a dedicated register type, (not an industry term, exactly).
So, for example a block move on the Z-80 will have formal requirements, such as 'put count in such and such (B and C up to 64k counts). Formally, put source pointer in HL (again 64k range).
  In your 6502 ASM world, the formality is maybe more limited in that the highest priority 'registers' are few.
But, and this is the magic of the 6502, you get a huge number (256) of next-highest registers; so many as to allow easy assignment of a couple HUNDRED variables, just sitting there for dedicated and rare use. Who cares, if register #117 contains a count of how many wombats fly East every hour, my Wombat subroutine is just going to keep a privately owned bin there, maybe only reported each month, or some dang thing the person writing the ASM wanted.  You see the maintaining or separation of function, but without swapping things around, to prevent harmful mixing of Wombats with 'Zebras', in on-going accumulation of data results.
  Uh, not clear, huh? So consider in using a solar system analogy.  A Z-80 might be like having a SUN with 4 planets, plus a swarm of meteorites way out. The access to the 4 very-near planets is excellent, while the further off asteroids are required as well, as the highest priority (Z-80 registers) are very limited in quantity and thus likely transient.
 A 6502 however, has next to highest working registers  residing as 256 'page-zero' mapped', thus maybe permanent, meaning some manipulations (increment decrement) can occur directly and be done.
  Then, even more mapping allows a third tier mapped' into the space from 256 thru 64K bytes.
A sort analogy of a planetary system having 3 rings of multiple planets.
Rescue of Z-80 CPU preference comes largely from the 16 bit functions closely accessed. But I'd bet many factors such as having dedicated Z-80 support IC's such as Z-80 CTC, Z-80 SIO and a plus for looking like conventional expectations, maybe of some VP of Engineering somewhere.
  The , 6502, can wrong or right, look a bit flakey, considering emerging 'hobby' image.
  Uh, how was this, then?  (I think 34 readers just quit and became antique furnishings dealers.)
-thanks, RJ