English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 17 July 2017, 13:26   #61
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,253
Quote:
Originally Posted by guy lateur View Post
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.
matthey is offline  
AdSense AdSense  
Old 17 July 2017, 19:39   #62
guy lateur
Registered User

guy lateur's Avatar
 
Join Date: May 2017
Location: Belgium
Age: 44
Posts: 212
Quote:
Originally Posted by matthey View Post
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.
guy lateur is offline  
Old 17 July 2017, 22:28   #63
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,253
Quote:
Originally Posted by guy lateur View Post
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.

Quote:
Originally Posted by guy lateur View Post
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 .

Last edited by matthey; 18 July 2017 at 21:49.
matthey is offline  
Old 18 July 2017, 17:57   #64
guy lateur
Registered User

guy lateur's Avatar
 
Join Date: May 2017
Location: Belgium
Age: 44
Posts: 212
Quote:
Originally Posted by matthey View Post
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!
guy lateur is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
AmiDevCpp and Floats AmigaEd Coders. General 0 18 January 2006 03:16

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 16:45.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.16161 seconds with 14 queries