colin_fox@outbound.wimsey.bc.ca (Colin Fox) (04/06/91)
I must say that I find this whole issue of Assembly Language programming and Good programming (as if they were separate) interesting, since not too long ago I was a staunch Assembler (I would ridicule anyone who programmed in C as being a 'wimp'), and now I do most of my programming in C. The first thing I have to say is - since I'm doing ALL of my programming on the Amiga (for the next couple of years, at least), it does me good to learn about the internals. Also, when trying to debug C code, I can examine the 68000 output for either problems in the compiler, or subtleties that aren't obvious from the C source. I've also learned a few humbling 68000 tricks from the compiler (SAS/C), which I must say is awesome. I've programmed 68000 for four years, so I'm quite comfortable in the language, but obviously not a total know-it-all. :) Now that I've had the luxury of using a powerful C compiler, I have to say that the ultimate combination of programming almost anything on the Amiga is a ratio of something like 80-90% C, 10-20% ASM. (Remember the 90/10 rule? 90% of the time for your program is in 10% of your code?). For high-level structures, there's no competition. C is easier. For example, it is quite easy to change a structure definition (especially with sub-structures) in C with a simple Search/Replace from your favorite text editor. But from assembly you have to go again over your program carefully and modify the references, to make sure that if any have changed too much, you might want to re-think that part of your code. Also, I've found that working in C (which is faster to slap together code), I can spend more time on the structuring of the program, and less on the 'niggley little details' that ASM forces you into. Basically, if you have to concentrate on tiny details throughout the whole program, you will eventually get fatigued with the tiny steps ASM forces you to take, and you will begin to get sloppy. But if you do most of your work in C, ASM then not only makes a refreshing change (good to change mental gears once in a while), but you aren't bored with it, and can concentrate on making the best of an algorythm. As for games, I've got a game on the market right now (Wings of Fury, published by Broderbund), written in 99% 68000. (that project was my first game, by the way, so no thrown veggies, please! I'll do better next time). ANyway, that was a MASSIVE project in 68000, with about 300K of source (all 68000 source), and by the end of the project, I could feel the whole thing creaking under it's own weight. I would fix a bug here, and something over there would break. My coding practices weren't the best when I started, and it really showed at the end. (By the way, the only things I'm proud of in the game are the bomb & rocket logic, and the Flagmen. THey were fun to do, and I used some high-level algorythims with low-level implementation). I would NEVER EVER EVER do another large project in 68000 again. There's no point. The SAS/C compiler can produce code almost as good, or as good, or sometimes better than I can, so why bother? The main thing that 68000 has taught me is how to code well in C for the Amiga. Understanding the underlying hardware is important for a 'small' computer. If you were programming on a mini or mainframe, you shouldn't care what the hardware looks like, but on a home computer, it makes a difference. So, to sum this rather lengthy message up - I do almost all of my work in C, but my assembly knowledge has been VERY useful. IT also allows me to know when to use which language. It becomes immediately apparent when something should be done in assembly. You shouldn't use a language just because you like it, you should use what's appropriate to the project. Part of the previous discussion was what makes a good programmer. I think that a selection of languages is what makes a good programmer. I can program in REXX, C and 68000, and that combination serves me very well on the Amiga. If you can make a quickie program in a couple of lines of REXX, then you would be silly to try to do it in C or ASM. (stepping off soapbox). Thank you.
dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) (04/09/91)
In <colin_fox.3793@outbound.wimsey.bc.ca> colin_fox@outbound.wimsey.bc.ca (Colin Fox) writes: >computer. If you were programming on a mini or mainframe, you shouldn't care >what the hardware looks like, but on a home computer, it makes a difference. I've got news for all the C-types ( I know, strong typing is for weak minds ) out there. I write 99% C, since I work in the UNIX environment, now, but I've also made as living a an assembly language programmer, and may do it again. Anyway, I've heard C-types say that the language should always produce the best code, no matter the platform, but that's just not possible. Current example: Stepping through a received data packet, checking header parameters that are bits in various bytes (SNA). I was asked by a colleague, "why use "cp++", when header[various constant offsets] works better?" The source was on a 68K, moving to an '86, and his experience is '86. So, I showed him the timing for a post-increment address-register- indirect, on a 68K, and he said "Oh!". The array-offset form is cleaner/faster on an '86, though, since it does't have the 68K address modes. So, the C source makes some decisions for the compiler that are pretty hard to optimize around. And some C source will work better on some processors than others, even roughly equivalent CPU's. Furthermore, just because the code runs on a mainframe, or super-mini, doesn't mean that code size is irrelevant. A small mis-optimization may make your code cross page boundaries unnecessarily, so, you get to go to disk for that page. Even mainframe drives are slower than Amiga CHIP RAM. It is nice to have some hardware background, in any low-level language like C. It is imperative to have a good knowledge of algorithms in ANY language. While you can, eventually, code all algorithms in assembly, some of them fall very nicely out of higher-level languages. The good programmers can, therefore, use the most optimum (speed/size/project schedule/etc.) languageS, emphasis on the PLURAL, for the task, and have enough education and experience to discern which is which. My 2 pfennig. By the way, some compilers/libraries are optimised for benchmarks. What does your "strcmp()" or "memcmp()" do when passed identical addresses, which is hardly common practice, EXCEPT in benchmarks? Dan Taylor * My opinions, not NCR's *
ben@epmooch.UUCP (Rev. Ben A. Mesander) (04/09/91)
>In article <1991Apr10.000254.24530@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes: [...] >With data abtraction, you can operate on structures and not >even know what's inside them! Hah! I can do this is almost any language! I don't need C++ to help me do that! Folks, take this thread to comp.sys.amiga.religion or .flame or whatever K*nt decided to call it. Or some other group. This is for the discussion of Amiga programming, not the One True Programming Language. -- | ben@epmooch.UUCP (Ben Mesander) | "Cash is more important than | | ben%servalan.UUCP@uokmax.ecn.uoknor.edu | your mother." - Al Shugart, | | !chinet!uokmax!servalan!epmooch!ben | CEO, Seagate Technologies |
sschaem@starnet.uucp (Stephan Schaem) (04/10/91)
Well I find the contrary.Structure are easyer to handle/anderstand in ASM. (That for me people). I have more than 500K of source on my curent project.Of course this is not comment striped:-) And still have 178K of structure definition. The above is for the main part of the game.Not including the 8 other parts and utilites (bigger than the game). It's not 1 guy work also... But doesn't make things easyer:-) We change structure ALL the time, no problem! the only problem come when we have commented a structure has the element cant change order... But never happen really:-) look at CBM structure, the same happen with Y,X... I would say that programing technics can make a diference! look at your code during the years... I pretty mutch know that you can make C code unreadable! and even almost untoucable! (Not coded by a pro). The same can happne in ASM also, its still a language. I cant beleive people that know the 680x0 put it down for C?!? I would not need mutch to look like C...
rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (04/10/91)
In article <1991Apr9.204318.6798@starnet.uucp> sschaem@starnet.uucp (Stephan Schaem) writes: > > Well I find the contrary.Structure are easyer to handle/anderstand in > ASM. (That for me people). > I have more than 500K of source on my curent project.Of course this is > not comment striped:-) > And still have 178K of structure definition. > The above is for the main part of the game.Not including the 8 other > parts and utilites (bigger than the game). > It's not 1 guy work also... But doesn't make things easyer:-) > > We change structure ALL the time, no problem! the only problem come > when we have commented a structure has the element cant change order... > But never happen really:-) look at CBM structure, the same happen with > Y,X... > > I would say that programing technics can make a diference! look at your > code during the years... Yes, the programmer accounts for some of the responsibility in maintaining structures, but doing it yourself in asm is still the hard way of doing it. And if you consider C++ or other object oriented languages with data abtraction, the problem goes almost entirely away. With data abtraction, you can operate on structures and not even know what's inside them! You can hide some details of the structure, and change them without altering a single byte in the rest of the program. With operator and function overloading you can almost totally ignore data types. For instance, you can declare a vector or matrix and add them as if there were normal numbers. Even better, you can change the definition of a "vector" internally and have the rest of the program work perfectly with the change. Object Oriented, Functional, and Imperative languages all have their place. You seem to suggest assembly is the only language for real programmers which is ludicrous. I could go so far as to say that only real programmers program in HEX or Binary. Or only real programmers program by flipping switches on a TX-0 or key punching a card. > I pretty mutch know that you can make C code unreadable! and even > almost untoucable! (Not coded by a pro). > The same can happne in ASM also, its still a language. > > I cant beleive people that know the 680x0 put it down for C?!? I would > not need mutch to look like C... I get the impression that assembly is the only language you know. Perhaps your sampling of various languages is limited, but there are many RICH programming languages out there. Trying to use assembly for every job is overkill. If assembler was the ultimate of all languages then why do people keep inventing new languages? To make programming easier. The vast majority of software in this world is developed in HLLs. The type of niche programming you do would be better directed at game controllers like nitendo , sega, etc. -- /~\_______________________________________________________________________/~\ |n| rjc@albert.ai.mit.edu Amiga, the computer for the creative mind. |n| |~| .-. .-. |~| |_|________________________________| |_| |________________________________|_|
sschaem@starnet.uucp (Stephan Schaem) (04/11/91)
Pretty weird AGAIN.I must be writting stuff when I sleep:-) (almost true) Well I never talk of asm being the one ond ONLY! Anyway check your history before you start saying sutch things to someone, thank you! Also its true that I dont know many high level language... the only stuff I done in high level is classes in advanced Pascal (never done any plication of it:-( , advanced C ( port some IRIS code for image display) and 7 month by porting PC source to the amiga. And that is not where I learn my programing technics! The amiga OS (Exec) is the one:-) And I change structure, usally move variable around... but changing data type is something that never came to mind! When I write the routine that interprete the structure I know the kind of data it need (curently or in future implementation). And I dont go change data type... It would be like, ok my aplication work on a 200 screen so I need byte size Y coord... than ok I will do something on a interlaced screen. If you change data all the time something went wrong (data type to be precise) Also data type is something I think is AGAINST me is not something to protect me or help me... So people can apreciate, but there is more than one type of software needs. But if you tell me I'm dont dont anything about other LANGUAGE than assembly you dont seem sharp on the 680x0 etheir and macro assembler. I can change TONS of structure definition and simply need to recompile... Because some people have the idea to use macro to create structure.What in C? you have 100 or 200K of structure definition and then.. poof major shift... what happen to you.Dont you have to do a little more than compile. And if you look closely you will see the resemblance of macro programing with C.Macro definition, both have the posibility (so you could do it in C for your structure:-), contional assembly etc... Those are the 2 that come to my mind when I think of C and MISMA (Motoral Instruction Set Macro Assembler,not assembly pure and hard..) Again the problem that you anounced is a programing technics and could happen in both worlds. To show you how techics evolve... I dissamble on of my first assembly program NS and so hundreds of reloc, than a copy programe I done last year and had none.? In both I used custom screen with windows and gadgets (around 53 avtive gadget in the copy programe). But if you have other example... Since you know both worlds more then me please give the MISMA side with your C. And maybe I could find another to do it. Stephan.
sschaem@starnet.uucp (Stephan Schaem) (04/11/91)
Also MR.Albert, if I was thinking ASM was the ultimate language why would I want to create an 'object' oriented 'language'? And why to you think I only support MISMA? Why do I refuse to work on nitendo? Why do I dont bother with intel? Why would I programe think of making pure code? Why do I think of concurent execution when I write my library function? And why I choose MISMA is related to my envirorment. Attacking people with stuff like saying they should be a nintendo programer is not very strong. And since you never saw what I do I dont see why personal attack have to take place? I just said I dont see why... not that it should stop:-) Stephan.
m0154@tnc.UUCP (GUY GARNETT) (04/12/91)
About the only comment I have to make is where you say "If you were programming on a mini or a mainframe, you shouldn't care what the hardware looks like". I would like to point out that the difference between modern home computers, minis, and mainframes is no longer one of kind, but is one of degree: mainframes have more memory and faster I/O. The IBM 3090 I use here at work is actually a much more primitive architecture than the 68000. Even when programming in FORTRAN, a knowledge of the machine will help. For example, when placing variables in a COMMON block, they should be arranged so that variables (especially arrays) start on longword boundries (because non-longword aligned fetches involve extra memory cycles). Performance is also enhanced when arrays and COMMON blocks are less than 4096 bytes long (the maximum displacement for relative addressing in the S/370 architecture; displacements of more than 4096 bytes require an additional base register, or require address arithmetic; the compiler will choose which one is faster). As you can see, knowledge of the hardware will help you write better programs, even on a large mainframe. You can also see how primitive the architecture of the 3090 (which is an S/370 machine) really is: there are 16 32-bit registers (one of which has special meaning as the program counter in some instructions) which can hold addresses or data. There are no stack instructions (if you want a stack, you can write the macros yourself), and there are no subroutine call instructions (again, you write the macros yourself, and dedicate a register to point to a save area which holds the caller's context, including program counter). Knowledge of the hardware and machine architecture will always help you write better programs, but it is not required to write decent software, or to be a competent programmer. I strongly suggest that anyone who calls him or her self a programmer learn as much as possible about the hardware, and also learn as much as possible about mathematics; in many ways, computer programming is "mathematical engineering". Wildstar