[tryphon]

Are you kidding ?

When you code in ASM, you have to know :
- what's the size of the registers
- what's their name (mmh. Z80...)
- if you can use them (and since you don't always know how you came to this precise instruction, you don't always know what they contain)
- if the operation you made on them concerns the LSB, LSW or whatever
- if they suppose the value is coded BCD
- etc., etc.

And I don't speak about tests, where you must know what precise bits of the CCR are set or not according to the operation.

And I don't speak about subroutines calls, where you must sometimes store then get back the return address (mmmh MIPS)

And I don't speak about old processors, lacking of index registers, where you have to make 'move's into the source code itself as a workaround.

Of course, a 'high-level language' coder could overload the '-' operator so as it does some weird operation, but in this case, it's the programmer fault. It just means that if you want to make an ununderstandable code in whatever high level language, you can.

But if you want to make an elegant code easily understandable, it's easy to do with a high-level language (mmmh CaML, I love you). I strongly have doubts about asm.

[Bregalad]

No I wasn't kidding, and I was just saying ASM is easier to understand - I said it was harder to work with, which is basically what you're saying, so we both agree. I never said ASM was elegant, either.

Overloading - can be your "fault" (using your own term), but it might more likely be the "fault" of the library you're using because either 1) everyone uses this library and 2) this is the standard way of doing it and your language doesn't offer any alternatives.

Just ask a random OOP programmer how complex is string concatenation with "+". Nobody even thinks that this will allocate memory for a new String object concatenating both strings and so on, unless explicitly asked.

I think our agreement comes from the definition of what is "understood": You're telling me that an algorithm written in high level is easier to understand, which is true, and I'm telling you individual instructions in ASM are easier to understand.

EDIT : I saw you mentionned MIPS, and I'd say that it's a great exemple : MIPS instructions are even simpler than say 6502 instructions, as there is no status flags, multiple adressing modes or register non-orthogonality, so this makes MIPS instructions simpler to understand. However, a MIPS assembly program would be even harder to understand, because more instructions should be used in a more tricky way to get the work done.
Basically programming is a trade-off between simplicity of the individual instructions, and simplicity of the whole programs. Assembly goes for the former, high level OOP for the later.

[tryphon]

No I wasn't kidding, and I was just saying ASM is easier to understand - I said it was harder to work with, which is basically what you're saying, so we both agree. I never said ASM was elegant, either.

I didn't say you say asm was elegant either

Overloading - can be your "fault" (using your own term), but it might more likely be the "fault" of the library you're using because either 1) everyone uses this library and 2) this is the standard way of doing it and your language doesn't offer any alternatives.

If you use a library without having the slightest insight of how it works, then this is your "fault" (using my own term). Note that my exact saying was "the fault of the programmer", not "yours". After all, ther's a programmer behind a library.

Just ask a random OOP programmer how complex is string concatenation with "+". Nobody even thinks that this will allocate memory for a new String object concatenating both strings and so on, unless explicitly asked.

I agree with you on the fact that many bad programmers use high level languages (especially C++).

I agree too on the fact that any coder should have a deep understanding of low/mid level languages (asm and C) because at this level, you must understand how things works at the memory level, and why copying strings is usually bad. Many coders lack of knowledge in algorithms too.

I think our agreement comes from the definition of what is "understood":

that's why I asked you earlier to clarify this word.

You're telling me that an algorithm written in high level is easier to understand, which is true, and I'm telling you individual instructions in ASM are easier to understand.

Honestly, I don't think. There are many instructions for similar tasks (in 68000 : move, movea, lea,...). More, they often have different little-known side-effects (on the CCR for example) whereas their main effects are similar (again, 68000 ; there's an article on the subject on Easy68K website). More, their names are cryptic.

Most high-level languages have very few instructions, and the most used are easy to understand.

Let's try python : the most common instructions are print, for, def, arithmetics and logics (with quite widespread notations). I think most coders (even bad) understands what they mean.

EDIT : I saw you mentionned MIPS, and I'd say that it's a great exemple : MIPS instructions are even simpler than say 6502 instructions, as there is no status flags, multiple adressing modes or register non-orthogonality, so this makes MIPS instructions simpler to understand. However, a MIPS assembly program would be even harder to understand, because more instructions should be used in a more tricky way to get the work done.

Damn delay slot !!!

Nonetheless, I studied and modified codes mainly on PS2/PSP (MIPS) and Genesis (68000) and I didn't find one easier than the other excepted on the fact that good debuggers exist for Genesis, and none for PS2/PSP, to my knowledge)

Basically programming is a trade-off between simplicity of the individual instructions, and simplicity of the whole programs. Assembly goes for the former, high level OOP for the later.

I think by 'simplicity of individual instructions', you speak as if you were a processor And I get your point. But for a human, I think that's not the only point of view. CaML again has very few instructions (to the least, I use really very few), they are very simple, and it forces you to think in such a different way... BTW, you're forced to understand why string concatenation is bad with it too !

Nonetheless I doubt anyone would use asm because instructions are simple (or else beginners would start with asm, which is rare), but because it's fast (provided you wrote an efficient algorithm).

[Bregalad]

I never learnt python, but when someone showed me a phyton program, I didn't understood a single bit of it.
On most other HLL, I'd understand at least some parts of them.

And even though I know that string concatenation is "bad", I use it all the time when I develop in HLL because I simply don't care. So if even I do it, imagine somone with 0 knownledge of processor architecture and of assembly.

The problem is that many types of programmers could be "bad" programmers in someone's eyes, and good programmers in some other guy's eyes.
For example I'd consider someone who tends to create lots of new instances of objects a bad programmer (even if perhaps myself would do this, because I don't care when I use HLL). But someone else would consider me a bad programmer because I try to be efficient instead of making code sexy. In the end, it always fall back to "I'm the only good programmer in the world, because I don't understand other people's programs".

Technically I started with Basic, but I soon learned ASM, and I remember having a lot of fun in doing so. There was a long time where I was only proficient in 6502 ASM and nothing else, which was problematic to create programs for my PC. Thanks god this period is over and I'm glad I learned to use HLLs, but while the HLL concept will help 99% of the time, they can be very handicaping for 1% of the time. It's hard to explain, but just try to do a right rotate in C, and you'll end up saying it was better in asm. Now just try to do a right rotate in Java, and, oh well, it'll be a major headache with the compulsory signed types and so on.

Delays slots are a terrible idea. Whoever had the idea to introduce them was seriously retarded. Removing them is very easy and requires few additional hardware. Keeping them means 1) coding in ASM for the processor is a torture and 2) it will be problematic for future expansion of the processor.

[henke37]

_lrotr. Looks like it is easy to do a bit rotation in C.

[KC]

Delays slots are a terrible idea. Whoever had the idea to introduce them was seriously retarded.

That's not true. MIPS was made to be a simplistic CPU, with a low complexity compared to CISC CPUs. The instructions were simplified, fancy features like branch prediction were out, etc. One effect was that you typically need more instructions to accomplish the same thing. Now, a branch causes the pipeline to effectively be flushed if the branch is taken, so it's wasting precious time doing exactly nothing. The idea of executing the next opcode after a branch to avoid some empty stalling time is actually a pretty clever solution to that, and it's effortless for compilers to make use of it.

[Bregalad]

On the RISC processor pipline I've worked on implenting in a FPGA, there was no branch predictor, yet branches were taking only 2 cycles when taken (and would flush the pipeline). Yes it takes more time, but the reward is no delay slots and that's a big reward.

In the end it's always a trade off. But I imagine it should be horrible to simulate 1 or 2 cycles delay slots on a bigger pipeline of a later CPU where those would "naturally" be 3 or 4 cycles by not flushing the pipeline, but you have to partially flush it to simulate the effect of the older processor for the same of compatibility.

[BRPXQZME]

For example I'd consider someone who tends to create lots of new instances of objects a bad programmer (even if perhaps myself would do this, because I don't care when I use HLL).

Plenty of programmers do make instances willy-nilly because they don’t know better, but there are actually a number of advantages to this approach if worked properly, which is why a lot of new HLLs keep making it work this way. You may lose on memory usage and speed, but speed can sometimes win big (e.g. for lockless multiprocessing reasons) and it can really make correctness a breeze (e.g. if you can perceive a series of transactions instead of having just the current value of a variable, without having to write your own logging or trace it by hand or whatever).

It seems irrelevant in this emulation/game-focused corner of the programming world where we often feel that we can’t spare room in cache for that, but then some hackers just said they’d love to know where changes to certain data came from, so....

If you’d like to know more, Rich Hickey did a talk called “The Value of Values” where he encourages programmers to try going beyond “place oriented programming”. Some of it went over my head, and he admits right at the beginning that you wouldn’t want to do this everywhere, but he does present a case for choosing values over variables way more than we do.

[tankendog]

Currently my Senior Research project is making a SNES game. 

There is way more than just learning to code when it comes to programming for the SNES.

You need to know ASM programming, 65186. 

You need to know what the registers are/do.
   
This is the hardest 2 things.  As asm is simple its using it in conjunction with the hardware to program.  Resources are there, but none are going to allow you to sit down and code mario from scratch.  Most resources were fan made.  Most are outdated, and terminology is hit/miss. And figuring things out can be extremely frustraiting.  I still cant figure out how to scroll horizontally/view tiles I store into vram.  And OAM is insanely hard to understand by the limited documentation, I had to scrap 3-4 weeks worth of effort because it is almost impossible to debug the code.   I am glad I got a chance to experience this, but it would be even easier to write pseudo-snes style game engine than to program in the SNES language itself.

Off topic a bit, But does someone know how to scroll the screen to the right and left?  if someone could PM me, Id make babies with you. <3

[ARM9]

This is the hardest 2 things.  As asm is simple its using it in conjunction with the hardware to program.  Resources are there, but none are going to allow you to sit down and code mario from scratch.  Most resources were fan made.  Most are outdated, and terminology is hit/miss. And figuring things out can be extremely frustraiting.  I still cant figure out how to scroll horizontally/view tiles I store into vram.  And OAM is insanely hard to understand by the limited documentation, I had to scrap 3-4 weeks worth of effort because it is almost impossible to debug the code.   I am glad I got a chance to experience this, but it would be even easier to write pseudo-snes style game engine than to program in the SNES language itself.

Not trying to be condescending but that's not quite true. In fact I'd wager that there's a higher quantity of helpful resources available today than what the developers had back in the day. I still think book1&2 are quite useful though, a lot of documentation on the net seems to have been derived from these as well.

Off topic a bit, But does someone know how to scroll the screen to the right and left?  if someone could PM me, Id make babies with you. <3

PM me and explain what exactly is going wrong and I just might take you up on that offer.

[Nightcrawler]

And OAM is insanely hard to understand by the limited documentation, I had to scrap 3-4 weeks worth of effort because it is almost impossible to debug the code.

Try this. I don't know why you are having so much trouble debugging your code. I would imagine you may not have knowledge of all the tools at your disposal. What are you using? what problem are you having that make it 'almost impossible' to debug?

[Bregalad]

@TANKENHOG : The difficulties you're talking about are typical difficulties of a newcommer to a particular platform. (i.e. you want to achieve X but don't know how to do it, or the system don't do what you want it to do when you try to do X).

They are very different from difficulties related to programming languages themselves.