understand c programming logic but can't write a tough program

[bsudbrink]

One thing that requires careful attention with comments is to keep them in sync with code changes.  Many times I have seen cases where detailed comments "evolved" into incorrect comments.  All of the "old hands" knew the comments were suspect but it made bringing on new people harder.

[brucehoult]

I certainly wouldn't prefer a 6502 to a Z80 (or even an 8080) but that's just me.  I did a bunch of work attaching early hard drives to Apple IIs and, of course, the driver had to run on a 6502.  Maybe I just didn't have enough time in grade.

The 8080 looks like it should be better than the 6502, with 7 bytes of registers instead of 3, but they're so restricted that's it's just frustrating. You can fit in a fairly nice looking memcpy() or memcmp() or strlen(), str[n][cpy,cmp]() with 16 bit src and st pointers and length, and the code is even quite compact e.g. 9 bytes in the loop (13 total) and 48 clock cycles per byte copied for memcpy(). The z80 is slightly slower at 50 clock cycles per byte.

But anything more complex at all and you simply don't have the resources.

Even then it's annoying that inc/dec of a 16 bit register pair doesn't set any flags, so you have to do something janky like copy one half into A then OR the other half, then check if A is zero (or AND the two halves if you want to check for -1).

6502 handles these simple loops worse, at least in code size and complexity. e.g. suppose dst, src, and sz are in pairs of zero page locations.

Code: [Select]

    ldy #0 ; 2 bytes, 2 cycles
    inc szh; 2 bytes, 5 cycles
    ldx szl ; 2 bytes 3 cycles
    beq decSzh ; 2 bytes, 2 cycles (not taken 99.6% of the time)
    inx ; 1 byte, 2 cycles
loop:
    lda (src),y ; 2 bytes, 5-6 cycles
    sta (dst),y ; 2 bytes 6 cycles
    iny ; 1 byte, 2 cycles
    beq nextPage ; 2 bytes, 2 cycles (99.6% not taken)
decSz:
    dex ; 1 byte, 2 cycles
    bne loop ; 2 bytes, 3 cycles (99.6% taken)
decSzh:
    dec szh ; 2 bytes, 5 cycles
    bne loop ; 2 bytes, 3 cycles
    rts ; 1 byte, 6 cycles

nextPage:
    inc srch ; 2 bytes, 5 cycles
    inc dsth ; 2 bytes, 5 cycles
    jmp decSz ; 3 bytes, 3 cycles

So we have a pretty large total of 30 bytes of code but only 20 to 21 clock cycles per byte copied, depending on the alignment of src.

The 6502 code is 2.31x the size of the 8080 code (your library is 17 bytes bigger), but the 8080 code takes 2.34x (2.44x Z80) more clock cycles to execute, every time you run it.

The Atari 400/800 run the 6502 at 1.79 MHz, so a z80 would have to be at 4.37 MHz to match it on memcpy.
The BBC micro ran the 6502 at 2.0 MHz, so a z80 would have to be at 4.88 MHz to match it on memcpy.


As soon as you have more variables involved in the loop than this, the 8080/z80 get a lot worse because you have to start shuffling things in and out of registers, taking a lot more code and a lot more cycles.

The 6502 doesn't get any worse until you run out of the 256 bytes of "pseudo registers" in zero page.

The z80 lets you have two more pointers in IX and IY registers, possibly freeing up BC and/or DE for more 8 bit variables. But the 6502 lets you have dozens and dozens more 8 and 16 bit variables in zero page.

[hwj-d]

Don't really know, what you mean with "lazy".

Do the thing well enough from the get go, so that you can trust it later on, instead of wasting time fixing small bugs all the time.

It also leads to the KISS principle and Unix philosophy.  Works well for me.

Nowadays, I mostly do C/POSIX/GNU low-level stuff, and Python for UIs.

My suggestion referred to the learner, who always runs into problems (syntactically, logically, language-dependent), because he doesn't do exactly this, namely to want to program much too large blocks at once, or doesn't differentiate into handy algorithm parts based on the overall goal. But this is exactly one of the essential points of the art of programming, which you learn by doing over time. So I was talking about the experimental phase of someone like the OP, who asked just that, who works out the programming precisely in this way of dividing it into manageable parts, and not to the professional in a productive environment, who knows, possibly still in a team. Learning isn't wasting time; someone have to do it bevore he/she is a productive programmer.

[Nominal Animal]

My suggestion referred to the learner, who always runs into problems (syntactically, logically, language-dependent), because he doesn't do exactly this, namely to want to program much too large blocks at once, or doesn't differentiate into handy algorithm parts based on the overall goal.

Yes, exactly: and that is the short-sighted kind of laziness that leads only to more work in the long term.

Those of us who are truly lazy optimize their efforts over the long run!

Postponing work of an hour today so you need two spend two hours tomorrow on it isn't laziness, it is wasteful procrastination.

Keeping changes to a minimum testable set, then re-testing the code, may seem like "more work", but it really does minimize the effort needed to develop working code.

Learning isn't wasting time; someone have to do it before he/she is a productive programmer.

I wholeheartedly agree.  Well, actually, even productive programmers need to learn all the time, because it's not like you solve the same problem over and over again; you move on to new things.  Which is why learning through problems that interest you, is so effective, I think.

[westfw]

The 8080 looks like it should be better than the 6502

Meh.  They always seemed to be about equal in terms of real world performance and program size.  Apple/Atari vs CP/M was always ... unclear.
They're both pretty awful, and both after their subsets of "clever things" you can do.

The Atari 400/800 run the 6502 at 1.79 MHz, so a z80 would have to be at 4.37 MHz to match it on memcpy.
The BBC micro ran the 6502 at 2.0 MHz, so a z80 would have to be at 4.88 MHz to match it on memcpy.

(did you take into account the extra z80 features?)In any case, most Z80 systems WERE at least 4MHz, whereas most 6502 systems were <2MHz (and maybe video contention?  IIRC, the 6502 allowed video to be sneaky WRT shared memory, but many CP/M systems had independent video subsystems.)It's like comparing a 40MHz PIC with a 10MHz AVR (which was another often-argued comparison!)

[_Vlad_]

Well, i'm not a rocket scientist, but i think you can try to start from defining your playground.

1) What you want to program? What is your inner "engie-kid" tells you?
- Do you want to program microcontrollers?
- Maybe write OS drivers or even own OS, like good God Linus?
- Maybe just some general things like "program to do some calculations because i'm quite lazy and hate Excel"
- Maybe you want to create video games?
- Maybe you are so exited about Web-sites?

For example - my inner engie kid SHOUT LOUDLY as hell that i want to program things that do some stuff in real world. From clock to giant war robot.

2) When you hear yourself you can ask yourself "which language should i use?". Because lets be honest THERE IS NO ONE MAGIC BEST LANGUAGE. Every tool has it's own purpose.
Just try to find out what languages used in field of your interest.

For example. Microcontrollers? C. Maybe C++ (but, please. Don't go C++ madness with bare metal)
Maybe You want create small robot with some kind of raspberryPi. So your device HAVE OS. Well. It still C. It can be C++. But you can also use python.
Maybe it's some tool for automation for some process or you need to process some data in your Linux/Windows/Whatever playground on your PC? It still C. C++. Python. PUT FLAMES DOWN FOLKS! Java or C#.
Maybe it's WEB? Well it's still.. plus PHP and something that i will not say for religious reasons.

3) Start to do basic stuff. Like put "Hello World!" on your screen, or blink a LED on your board. You just need to become fammiliar with basics of your language. Dont worry, programming languages have quite easy rules compare to madness of Grammar and other stuff around any human language.

4) CALM DOWN. Yes, you will not be a rocket-scientist in 2 weeks, so you need to calm down about yourself. You are not the worst monkey on this planet and not a superman.
So main part of this step is to understand that you can do it, but there are 2 problems:
- you try to jump so high that your head will smash ISS. Find smaller project, that say to you "doooo it with mee"
- you just cant figure it out in your head. Try to find parts that are unknown to you. Engineers love to be simple. Maybe this over complicated device have really simple interface? Maybe you horrified about it, but when you will find information about it - you will find out that you need to say "Work, my little slave" and everything will be fine.

And try to figure out how to do it not in programming language. Think like you are the part of whole system. Think more abstract. Like "i need to get this number and put in this calculations".
When you understand what you need to do - it will be much easier to describe your actions in programing language.
And well.. you can sometimes visualize thing in real world. Like use boxes to store rubber ducks that you use like "data" and so on.

5) Don't cry like a Disney princess. You will get mistakes. A LOT. It's scary but it's a good sign that you are progressing.
We always fail. Failure is a opportunity to get a big "AAHHA!" when you find problem.
What difference between expert and beginner? Expert went through a lot of sh...t and failures. Expert will tell you "it's a bad idea" not because he/she is so smart, but because he/she get "Vietnam flashbacks" because they failed as you and now live with this pain and expertise.

Good Luck!