28 June 2023, 12:07 | #61 | ||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,330
|
Quote:
Quote:
Quote:
Quote:
Surely, somebody finally has to make the plan reality, but that's a craft, not an art. To explain you a little bit the difference in terms of software: graphics.library: "a coder's job". A pile of crap code, hard to extend, hard to maintain, not scalable, not extensible. Bad abstractions, too tight to the hardware. That's asm and C mixed. People just threw function after function into graphics "oh, here's another piece we can make use of". The net result are structures like "GfxAssociate" because its internal workings depend too much on all documented structures. A very bad interface. intuition.library: "an architect's job". Good structures, decent isolation of code and interface, extensible. That's C only. |
||||
28 June 2023, 12:25 | #62 | |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,200
|
Quote:
The AmigaOS is so decidedly obsolete now that the only purpose of Graphics.library is to be the glue between the OS and the chipset. One partucular optimization that 68k C compilers have yet to figure out is how to limit the register dumps to and from the stack at the beginning and end of every function respectively will affect only the registers actually used by the subroutine. PPC has some glue in its linker that allows only some of the registers to be stored. How many years until 68k gets this optimization? The world may never know. Intuition.library has loads of legacy code in it that hasn't been utterly replaced by more modular code. GadTools.library can't function without Intuition.library but in order to migrate the code to have the least amount of legacy cruft involved, the roles need to be reversed to get a pure BOOPSI implementation such that Intuition can be deprecated and evicted from future Kickstarts. I doubt that it will ever happen now, but as long as we can dream.... |
|
28 June 2023, 12:25 | #63 |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,478
|
You can do some very legal things in C that look simple but are extremely expensive in terms of processing overhead, memory and stack usage.
Things that today are mainly irrelevant to most programmers because all three are in large supply on modern systems. Some of todays embedded systems are very similar to home computers of the 80s and 90s in terms of their CPU power and RAM. It's practically impossible to recruit good software engineers to work in embedded programming who actually understand the ramifications of the C code they are writing. Most have been poisoned by decades of writing without caring at that level of optimisation. I'm the ASIC engineer (chip designer) but the number of times I have to say to the firmware engineers writing in C for my hardware "Do you actually understand what that is going to turn into?" I try to hire old skool programmers for embedded when I can. But most are in their 50s and demand salaries outside my budget these days. |
28 June 2023, 12:50 | #64 | |||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
Quote:
Quote:
Sorry, i still prefer the assembler - especially after having disassembled what this produces. Quote:
Quote:
Quote:
In short : both are important. Quote:
With "architect's job" it would only have made the system too slow to be usable. Quote:
Ah, and you forgot exec.library. Nice, easy to use, lean and mean. And 100% asm. Another "coder's job". |
|||||||
28 June 2023, 12:59 | #65 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,498
|
Quote:
My working career started as a programmer of embedded systems and I understand him perfectly when he says that it is now basically impossible to find programmers with the right mindset. It's one of the mistakes Thomas makes in his reasoning, it lacks contextualization. There's no point in making plans for a skyscraper if you're building a sturdy cabin in the desert. You always have to look at the cost/time/benefit ratio. This doesn't mean making a crap project, but using the right tools in the right place. However we are always talking about the Amiga and a hobby, it's okay to be a 'bad' software engineer / coder, the important thing is to have fun (no, there are NEVER too many 'coders'). And back to the original question: "Any reason to use assembly on Amiga rather than C?" Yes, if you think it could be useful, if this optimize and speed up your code in legacy machines, if you like 68k assembler and it makes you have fun. |
|
28 June 2023, 13:09 | #66 |
Alien Bleed
Join Date: Aug 2022
Location: UK
Posts: 4,542
|
|
28 June 2023, 13:18 | #67 |
HOL/FTP busy bee
Join Date: Sep 2006
Location: Germany
Age: 46
Posts: 32,057
|
|
28 June 2023, 15:32 | #68 | |
Registered User
Join Date: Dec 2017
Location: Austin, TX
Age: 41
Posts: 413
|
Quote:
Part of my job is maintaining the microcontrollers in GPUs. Until last year these were all programmed in assembly with a custom ISA. This year we replaced several of them with a new design targeting a standard ISA, so we could replace it all with C. The new hires' job was to handle this migration. Despite the initial performance being quite dire they managed to turn it around with GCC-specific performance hints, restructuring code into something more directly in line with the desired assembly, and replacing some parts with inline assembly. While I did enjoy being the assembly wizard I don't miss that codebase in the slightest. |
|
28 June 2023, 16:07 | #69 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,386
|
In a company project I had to look into, they had 99% Ada code and 1% asm code because Ada probably didn't handle shift bits too well.
So the time-critical code was asm, and the rest was Ada. You can't do otherwise in industrial projects. Not everyone can handle asm 8 hours a day |
28 June 2023, 16:33 | #70 | |
Registered User
Join Date: Jun 2020
Location: Another World
Posts: 28
|
Quote:
I teach code optimization in a university. I make my students disassemble a lot of GCC code. GCC 12 does a really crappy job on x64. Now just imagine what these compilers know about 68k. 68k asm is super easy and nearly feels high-level. So the question really is the opposite, why should you want to use C on such an amazing architecture that was meant to be coded in asm :-) A possible answer is to be able to port code from other architecture, but that's going to end up being slow. |
|
28 June 2023, 16:38 | #71 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,386
|
I 100% agree with that last post.
But take for instance powerpc, asm is so crappy you'd think they've wowed not to use vowels for mnemonics. That's when the bullshit about compilers doing a better job started, with the pipeline RISC shit. Someone once told me that some compiler (intel icc) had a 1000% speed rate compared to gcc. It was indeed on shitty code. On my code, i only had marginal gains because I wasn't spending my time copy/pasting the same shit over and over It had SSE support so in the end I used it. Some architectures are meant to be used with a compiler (PowerPC for instance, and compilers to a very good job with x86 and arm) but old architectures & high level languages don't mix well in terms of performance (8-bit C compilers generate a lot of code, and C is just not designed to run on 8-bit CPUs, 68000 also is really easy to code in asm, and C slightly confuses the code, specially low level) C was meant for portability, because they didn't want to port Unix on each target. But it's only high-level assembly. |
28 June 2023, 16:41 | #72 | ||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,330
|
Quote:
Quote:
First make it work, then make it great, then make it fast. In that order. The key to fast code is not assembly. The key to fast code is the right algorithm for the job. Once you have that, isolate bottlenecks, and *then* you can start thinking about rewriting those. Actually, 20 years ago we had our assembly expert in house who optimized the heavy-duty parts of the algorithm, but nowadays, that's another expert that uses compiler intrinsics to optimize the heck out of it. Of course, I know how to prepare layout and the classes such that SIMD can be applied, but that's part of the architecture. It's not so different for Amiga. Prepare structures such that you can isolate heavy-duty code, and then rewrite that part in assembly, but only that. P96 BlitBitMap() is a nice example of that - finding bitmap types, pixel types, locking hardware, identifying what the hardware can do, "high level code" and as such C. Blitter primitives for shuffling data around if the on-board blitter cannot do it: Assembler. Writing everything in assembler would create almost zero benefit, except that the code would be not maintainable. Quote:
Quote:
No, not for what it *should* actually do. They are only efficient for blitter hardware, planar bitplanes. But that's not what is actually needed. We have chunky, true-color, various F-Modes in the chipset... and for that, it does a pretty lousy job, and it is pretty hard to extend to make it work what it actually should do. If graphics had been designed (and not coded) it would have been more efficient at today's problems. The way how it is is that is actually less efficient than it could be. Thus, for example, graphics has to go through hoops with its "GfxAssociate" mechanism to find side-information its originally "designed" structures cannot hold. Quote:
Graphics *could* be a lot faster if it would have had a better architecture. The entire "bitplane" system it is based upon is pretty much a speed-brake. Quote:
GadTools is just (as the name suggests) a toolbox for intuition primitives, based upon what intuition has in its core system. |
||||||
28 June 2023, 16:50 | #73 | |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 5,068
|
Quote:
The answer in in this sole thread. Thomas does not comment much because C does not require much comments. Meynaf does comment because he is used to this good practice. But what makes you laugh today may not in 3 years. Thus explanations may help especially if the humour has or may have different audiences And with such thinking we finish with bullshit OS requiring a minimum of 8Gb of memory and multi core CPU to do what an OS of the 80' was able with 512Kb of memory and 7Mhz CPU (yes I intentionally mark red the line). |
|
28 June 2023, 17:04 | #74 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,330
|
Quote:
Quote:
There are reasons for the complexity, and there is a price to pay for the flexibility. |
||
28 June 2023, 17:47 | #75 |
Ex nihilo nihil
Join Date: Oct 2017
Location: CH
Posts: 5,068
|
Reason is called : business model.
Look how W11 has turned complex. An option that was easily accessible in W7 is now hidden under the submenu of the menu that is inside the submenu of the other menu. Yeah, really productive. Same for the new right click to access the properties. Not to mention outlook (and teams) opening all links by default in edge instead of the default browser. Complexity means most of the time : Pissing off users. There is no price to pay for flexibility. Flexibility is the default rule to apply. Not something you have to pay for because you are pissed off by the complexity that has been build to make you open your wallet. |
28 June 2023, 17:48 | #76 | ||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
Quote:
Your end users don't care how your program is written, how "maintainable" it is. But if it is crashy, is a resource hog and runs like snail, they will notice - no matter how beautiful its internal architecture is. Quote:
How many lines is relevant, simply because the longer a program is, the more difficult it is to handle. Sorry, but i prefer deciphering 10 lines of asm rather than 100 lines of C/C++. Quote:
Quote:
Yes the right algorithm is important, but if you use a slow language your program will be slow. Real life example : my jpeg decoder. My "slow int" implementation is faster than compiled "fast int" method ! Besides, choosing the right algorithm isn't easy if you don't know what the underlying code does. The fastest one isn't necessarily obvious to pick up. Good, compact data layout also helps a lot with speed, but with C you're just clueless. Quote:
Sorry, but you will NEVER reach the speed of my image viewer (which is faster than everything else) by just optimising parts of the code. But you're fancy a code contest maybe ? Quote:
Quote:
And no, the compiler is very poor about data shuffling. They constantly move things around as parameter passing instead of simply keeping same thing in same register. Quote:
Most of the stuff in a programmer's life actually is trivial - if it is not, either you're using the wrong approach, or you ought to split the task into smaller parts. Quote:
If graphics.library can't be enhanced easily, why wanting to do this. Keep it "as is" for compatibility and do something else. Quote:
Remember it is designed for running on a 7Mhz machine not doing whatever you may call "modern". Quote:
Quote:
Quote:
But that wasn't the point anyway. While some design decisions were good, others were not. Quote:
These reasons are not what you think they are, and the price is clearly way too high for the result we get. |
||||||||||||||
28 June 2023, 18:02 | #77 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,498
|
Quote:
It remains to be seen whether the quoted message was humorous or not Last edited by ross; 28 June 2023 at 20:32. Reason: The original message was timed, self-destruct has been activated ;) |
|
28 June 2023, 18:34 | #78 | ||||||||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,330
|
Quote:
Quote:
Now, as an exercise, take your existing code, and consider how much work would be needed to implement everything else in JPEG, and how much code you would need to throw away. Consider how much simpler the task would have been if you would have started from a code base that actually is "architected" instead of "coded". So maybe take this as a take-home exercise: With your JPEG code, go ahead and just assume for the time being it would be professional code that would be sold and paid for, for your daily income. Consider a customer would demand "I want lossless JPEG and 12-bit QM-coded JPEG processes". How hard would it be to support that from your code base, how much would you need to throw away, and how much you could reuse. That is *exactly* what software architecture is about. (I assume you probably had just taken Tom Lane's original IJG code and patched it up a little bit instead of implementing all of it from scratch, right? That's again the lazy way of doing. Tom's code does not have a particularly fancy architecture). Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Why do I want to do this? Because of customer demand, that's why. People wanted true color displays, people wanted more than 8-bitplane AGA, people wanted high-resolution displays. Graphics was and still is *in the way* to such demands, and it requires a lot more code to work around these problems than it would have needed to actually architect graphics correctly to begin with. It is the perfect example that "software is a moving target", and you better have an idea about that when you start such that you can adapt it to this target. Graphics wasn't, it is a pile of code, nothing more. But look, this is the *central thing*. "Original tasks" don't stay, they never stay. That is the entire problem we are talking about. Quote:
Quote:
Quote:
Quote:
Intuition could be. Whether a gadget is a struct gadget or a boopsi does not matter to intuition, neither to the program does not matter. Both work likewise. To graphics, a "struct bitmap" is always planar, and a "struct ViewPort" is always a viewport. You probably have no idea through which hoops graphics and P96 have to jump to retarget the graphics to non-native bitplanes - or even to AGA with multiple "monitor" definitions. To make this more concrete: If graphics had an "AllocBitMap()" function to begin with, an "AllocViewPort()" and an "AllocView()" and if its makers had never documented how these structures actually look like, and instead would have written manipulator functions for them (aka "methods"), graphics would be in a much better shape, and, as of today, actually faster than it is (yes, really, including on native planar hardware). I *do not need* C++ to write such code, but yes, working in its mindset helps, and having a compiler to support me in that also helps. If that is too slow, I can still care about that later, this is really a minor issue. You do not learn why such abstractions are helpful by "coding asm code". Too high for whom? Actually, the market success of Windows or Mac say the opposide. |
||||||||||||
28 June 2023, 19:24 | #79 | ||||||||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,365
|
When you compile code, yes. When you write it in asm, not always. Depends how good C source was (it usually is quite bad). With C++ and using classes, almost guaranteed to be smaller in asm.
Quote:
Quote:
Not a problem, I'm not using it. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
If it does not do what you need, no other program will. So you've checked your compiler's source code and algorithms to see how it does things ? You're becoming worse every time. Quote:
Quote:
Quote:
Quote:
Quote:
As you said yourself above, architectures don't resist the contact with reality. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Are you aware that their success comes from marketing rather than anything else ? |
||||||||||||||||||||
28 June 2023, 20:18 | #80 |
<optimized out>
Join Date: Sep 2020
Location: <optimized out>
Posts: 321
|
This is pathetic. Why are the EAB moderators allowing this to go on?
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Chat GPT Amiga Assembly | rcman | Coders. Asm / Hardware | 3 | 26 March 2023 20:24 |
An Amiga coder was banned without a reason - is it ok? | litwr | project.EAB | 1 | 18 June 2021 20:38 |
Beginning Amiga Assembly Tutorial(s) | Curbie | Coders. Asm / Hardware | 15 | 29 May 2020 00:21 |
Beginning Amiga Assembly Programming | Hewitson | Coders. Tutorials | 32 | 09 October 2012 18:25 |
Amiga Assembly sources - Please help! | W4r3DeV1L | Amiga scene | 21 | 16 July 2008 08:13 |
|
|