Integers vs floats (FFP/Sing/Doub) + printf()

[matthey]

Originally Posted by guy lateur

Darn, and I was so happy with my new lib..

It is helpful to have easy to use little functions and macros for quick testing and debugging (often not release efficiency or quality). It is more important to keep learning at your stage but there is more to know and do with assembler like performance considerations, code structure and organization, low level data type handling, etc. which high level languages often abstract away. It really should be learned from a low level first as the hidden abstraction is the source of much bloat.

[guy lateur]

Originally Posted by matthey

It really should be learned from a low level first as the hidden abstraction is the source of much bloat.

Although I do understand what you're saying, I'm not sure I'm going about this the right way. Coming from a C/# background (on modern pc hardware), I feel like I'm trying too much to code in assembler in the way that I'm used to when coding in C. It doesn't seem to work that way, however, as this and other threads have shown. Eg, what you said earlier about calling a subroutine yielding a cost that can actually significantly slow down your exe; I've never thought of that cost when using C. I've never programmed 'real time'/highly optimised software neither, btw. Also, I think I only know about 10% of the 68k instruction set, ATM, if that. So why on earth am I doing this in assembler?

So, as has been suggested earlier, wouldn't it make more sense if I started from C, and, if necessary, work my way down to assembler? Because I'm still trying to code some kind of demo, so performance will probably eventually become an issue. I feel like I've jumped into the open ocean going with assembler, while I should maybe learn how to swim in a swimming pool first and use C. It'll probably be easier to start out in a language that I know, so I can focus more on what I actually want to achieve. Ok, I'll still have to learn the hardware and the OS, but at least I'll kind of know what I'm doing, in C.

Anyway, I still enjoy what I'm doing right now (and the feedback I'm getting from this community); it's just that I may be making this unnecessarily hard on myself. I should at least further experiment with C, too, I suppose.

[matthey]

Originally Posted by guy lateur

Although I do understand what you're saying, I'm not sure I'm going about this the right way. Coming from a C/# background (on modern pc hardware), I feel like I'm trying too much to code in assembler in the way that I'm used to when coding in C. It doesn't seem to work that way, however, as this and other threads have shown. Eg, what you said earlier about calling a subroutine yielding a cost that can actually significantly slow down your exe; I've never thought of that cost when using C. I've never programmed 'real time'/highly optimised software neither, btw. Also, I think I only know about 10% of the 68k instruction set, ATM, if that. So why on earth am I doing this in assembler?

Is it easier to start with the simplest and most basic elements of programming and a CPU and build your knowledge up or start with someone's artificial abstracted ideas of programming and maybe work your way down to a low level understanding and efficient control of processors? The answer depends somewhat on how an individual's brain works but I believe someone who has learned from the bottom up instead of top down will usually have a better overall understanding. The problem is that you learned a high level language first so now you may need to unlearn some of what you learned and reprogram your brain. It is important to realize that programming a computer involves programming the computer and your brain at the same time.

Syntax is the easy part of a language to learn. Reading and referencing as needed the M68000PRM is a good start.

http://www.nxp.com/docs/en/reference.../M68000PRM.pdf

This M68000PRM is easy to understand for a low level technical document and is further helped by the 68k architecture ease of use in assembler (which was planned) but rarely seen in modern processors. The manual goes into basic datatypes used by the 68k and how to access them. Datatypes are important to learn after syntax.

Originally Posted by guy lateur

So, as has been suggested earlier, wouldn't it make more sense if I started from C, and, if necessary, work my way down to assembler? Because I'm still trying to code some kind of demo, so performance will probably eventually become an issue. I feel like I've jumped into the open ocean going with assembler, while I should maybe learn how to swim in a swimming pool first and use C. It'll probably be easier to start out in a language that I know, so I can focus more on what I actually want to achieve. Ok, I'll still have to learn the hardware and the OS, but at least I'll kind of know what I'm doing, in C.

Even 68k assembler can be tedious compared to a low level language like C (depending on what you are doing). It makes sense to do most programming in C but you would still benefit from struggling with the assembler until you are somewhat comfortable and competent with it. This can include using a debugger and/or disassembler on C code and studying the assembler code, stepping through it and altering and reassembling parts of it. You have already learned some about writing and using assembler functions and inlines. The vbcc and vasm manuals provide good documentation.

http://server.owl.de/~frank/vbcc/docs/vbcc.pdf
http://sun.hasenbraten.de/vasm/release/vasm.pdf

Programming the brain is more difficult than programming a computer and may require you to leave your comfort zone .

[guy lateur]

Originally Posted by matthey

Programming the brain is more difficult that programming a computer and may require you to leave your comfort zone .

Man, I'm already so far away from my comfort zone I can't even remember where I left it..

Thanks for your reflections on this, they make a lot of sense!