09 April 2022, 14:42 | #201 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
And anyway, not a good example : this is not typical stuff we're going to see on our 68k machines - if at all. |
|
09 April 2022, 14:49 | #202 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
The problem is that stuff ported from PC like that, is dead slow. I know, i ported a few things this way. And the only way to fix that is : rewrite it in ASM...
|
09 April 2022, 15:31 | #203 | ||
Registered User
Join Date: Sep 2013
Location: Poland
Posts: 868
|
Quote:
Quote:
|
||
09 April 2022, 15:55 | #204 | ||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
Quote:
Of course, they weren't very fast on the PC to start with, i.e. they often required a higher configuration than ought to be. This is the only advantage i can see for compiled code. As it does not help that much in later handling the code : rewriting C into asm isn't an easy task but the problem does not come from writing the asm : it comes from understanding what is that ***** original code doing ! Well, of course good C is easier to handle than bad C, but nevertheless. |
||
09 April 2022, 16:00 | #205 | |
Registered User
Join Date: Dec 2019
Location: Ur, Atlantis
Posts: 2,068
|
Quote:
Tbh, nothing could be perhaps better in at least some of these cases. For the life of me I will never understand the reasons to play gimped versions of these great games, only for the sake of doing it on Amiga (sort of). Frankly, I'd much rather see the most amateurish, bottom PD-level game instead, as long as it was an original creation. |
|
09 April 2022, 16:29 | #206 | |
Registered User
Join Date: Sep 2013
Location: Poland
Posts: 868
|
Quote:
|
|
10 April 2022, 00:12 | #207 |
Registered User
Join Date: Nov 2014
Location: Italy
Posts: 2,444
|
Amiga 68k softwares must run on any Amiga 68k model, not for a niche model only, because the risk is to have a more fragmented community and more hostility between various users in the long run.
|
10 April 2022, 08:41 | #208 |
Registered User
Join Date: Sep 2013
Location: Poland
Posts: 868
|
Well problem with that is 060-based turbo accelerators are rather scarce, just as expensive and they are slower (compute performance) so it's rather silly to expect games NOT being created to Apollo card users just because other cards can't keep up. Will PiStorm and Buffee make difference? Buffee in it's current form is just 68000 replacement. Chip itself is System on Package so consist SoC itself, memory die and few other things on common package. And from all of that only Amiga 68k signals come out. There's NAND memory controller (so eMMC, cheap "SSD" for Amiga) and PowerVR graphics integrated but unused. Maybe next design will use it. Or maybe next design will be on even newer chip (there are new with Cortex A53 and R5F and it costs roughly 3x more per chip and those from TI itself doesn't integrate RAM etc. so cost can go higher but it still is less than Cyclone V5 with 77k LE). PiStorm has it's own shortcomings. There are (are there still?) problems with access to chipset, musashi is slow but fairly compatible while emu is blazing fast but as JIT it either causes distortions or just crash the app itself (I believe that mostly happens with self modifying code though). But hardware-wise there's so much going on it would be a shame not to see any fruits of their labor (new apps and games).
|
10 April 2022, 10:30 | #209 | ||||||||||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
Quote:
A computer language is not just "something that will be executed by the CPU in the end", but it is something "a human needs to work on", so it is documentation and expression. Quote:
This nice toy example posted above where people compared a sort algorithm in C with an identical one in assembler was actually a very good example. It showed that for the simple bubble-sort, C code was only 7% slower, but it also showed something very important, namely that you need to use the right algorithm to begin with. If that program would have used a better algorithm, it could be more than 100% faster, depending on the data. Bubble sort is O(N^2), quicksort is O(N log N), so by choosing a better algorithm, you can gain a lot more than by choosing another language. Quote:
And this is just a trivial example. Quote:
Quote:
Quote:
There is rarely any program you write and then "it just works", but it is more write-update-fix-update-fix... because you get customer requests, feature requests, bug reports, and processing that with assembler is a PITA. Just a very simple example is change of interfaces: Consider you need to update a function to just take another parameter, as part of a feature request. In Assembler, you have to go through the entire project and find calls to this function, ensure you get the argument passed in. You probably need to re-allocate registers in each caller. In a higher language, the compiler will check for you. For some reason, you seem to assume that your development cycle is "write once - run program", but that's not how reality works. It is more "write-update-write-update-write-update" in an endless loop, and the "update" is not because I was doing bugs, but because people ask for features and improvements. Quote:
Quote:
Quote:
Quote:
Hardly. Complexity comes with the problem you need to solve. A problem doesn't get smaller by the language. Assembler just *adds* complexity on top of that by requiring you to do tasks the compiler or language can do for you instead. Like checking arguments or pointers. |
||||||||||
10 April 2022, 10:40 | #210 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
Quote:
However, that's not how the Amiga "market" works.Who is writing this software? The way how it is - we all depend on old software continue to work. I don't mind about the new instructions, registers... I wouldn't use anyhow, but I worry about old features getting removed or only implemented partially. First, get the basic job done, then care about the extras. But, the way how this goes, it is mostly about "shiny new features" rather than "getting the job done first". Certainly, the latter is more boring and more painful, but it a lot more important. |
|
10 April 2022, 11:50 | #211 |
Registered User
Join Date: Jun 2015
Location: Germany
Posts: 1,926
|
But a lot of the old software works fine on the new hardware. It is only some new specific software that doesn't run on old hardware. Of course, this new software is in the niche inside the niche but people with this niche hardware can walk out of their niche into the bigger niche.
|
10 April 2022, 12:18 | #212 | ||
Registered User
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 2,745
|
Quote:
Quote:
Yesterday I compared the speed of two 68k assemblers for the Amiga - ProAsm, which is written in pure 68k assembler, and vasm which is written in C. When assembling a typical medium sized project, ProAsm was 27 times faster than vasm. This speed increase is mostly due to using more efficient algorithms. Unfortunately the source code for ProAsm was never published. However since it was written in asm I know that a disassembly is not too far off from the original source. This makes it my best bet for creating an assembler that works 'perfectly' at a fast speed. vasm has source code so it is easy to modify, but it's dog slow in comparison which makes it unattractive. |
||
10 April 2022, 12:19 | #213 | |
Registered User
Join Date: Nov 2011
Location: Nuernberg
Posts: 824
|
Quote:
There is no language perfect for every task It all depends what you want to do Automate something Develop applications develop low-level stuff like drivers which platforms do you target (f.e. desktops or app development) how much developers are involved? what software development platforms are available targetting these platforms? How well supported and updated are these? Can they be extended? Which libraries/dll are directly supported and how good? The class-libraries, extensions and OS support are very important if you look at how efficient you can create something working. But of course you add a lot of overhead with it making the exe bigger and in many cases the software slower. All comes with a price. Even in old days 68k asm was used but mostly for speed reasons in some cases. Mostly it was a mixture of high-level language and asm. You cannot say asm is king, it all depends on what you want to do. Try to do a database based application with asm, it will unbelievable fast but you will propably die before it will be ready. On the other hand a game engine or raytracer in optimized asm would benefit very much from it. But both have the advantage to not depending on other resources. Last edited by OlafSch; 10 April 2022 at 12:54. |
|
10 April 2022, 13:15 | #214 | |||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
Quote:
Programming is not a static "problem->solution" job. It is a "problem->solution->new problem->next solution" job. The day you're ready with your first assembler approximation, I've already found better solutions for the next problem to come. Quote:
Now, that tells you a lecture more than the speed. Asm source is "outdated, unmaintained". High-level language source may be less efficient, but closer to the actual problem you want to solve. Quote:
That is *exactly* the problem with assembler code. |
|||
10 April 2022, 15:26 | #215 | |
Gimmemore Commodore
Join Date: Apr 2016
Location: Australia
Posts: 344
|
Quote:
What a load of nonsense! By that reckoning, there should be NO AGA specific software. Give me a break! |
|
10 April 2022, 16:17 | #216 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,317
|
This argument was probably correct 25 years ago where we had new development and a larger customer base. 25 years ago, you could also expect that users jump on a new hardware base, and vendors would provide software for it.
However, that hardware base turned out to be the PC, and thus Amiga stopped being an active platform. |
10 April 2022, 17:00 | #217 |
Gimmemore Commodore
Join Date: Apr 2016
Location: Australia
Posts: 344
|
I fail to see why that should dissuade anyone from at least having a shot at developing the platform further, especially if they have the means to do so. If a person doesn't want to buy into it, then move on. Last edited by sean_sk; 11 April 2022 at 00:57. |
10 April 2022, 17:09 | #218 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,546
|
Quote:
If you like to develop and assemble on your Amiga directly I would never recommend vasm. There are enough alternatives which work fine. Starting with 060 or modern systems I wouldn't miss the features of vasm and assembly time is neglectable. Quote:
The two main reasons for using 68k assembler are: Writing Amiga programs which are performance-critical (mainy games and demos). Having fun with 68k coding and optimization. There is nothing wrong with that! |
||
11 April 2022, 10:52 | #219 | |||||||||||||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
About "organize code", i want to do that myself. As what is made by HLLs is quite often inadequate for the task at hand and we end up spending more time fighting the development environment than doing actual code. Quote:
If it's just 10% then the code isn't cpu bound or nobody did proper asm optimization (a likely case for pc-like machines). Fancy a code contest to prove your point maybe ? Quote:
Yes a better algorithm can help, i wouldn't use bubble sort anyway in asm, but sometimes it's not enough. My asm implementation of jpeg's "slow int" DCT ended up significantly faster than compiled version of "fast int" one. Quote:
In asm, true, i had to solve these, but not again and again for every project. I wrote my own string handling routines to handle all this buffering issues and more, same for dynamic arrays. Now i just reuse that. Indeed. HLLs fail even more when it's not trivial, for the simple reason their designers couldn't think about every possible case. Quote:
But my point is only about 68k as it's the only architecture for which asm is enjoyable (except my own vm but it's another story). Quote:
You have to understand that everything becomes asm one day or another, be it by hand or by compilation. So, by definition, everything is doable in asm. I could easily fool you But i will not. If i can do it in another language, i can do it in asm - but due to the everchanging web specs, it's a full day job and not for a single coder. I have better ways to use my time. Quote:
You can always find examples of bad software, no problem. You can't be sure, however, that a C version wouldn't have been worse. I can give an example too. Take MEmacs from original AmigaOS (up to V39, it's maybe fixed later, i dunno). It's all C. It's terrifyingly slow when you open or write large files, but not only. Try to search for a text containing accentuated characters (f.e. umlauts) and it will fail, mismatching them for control chars. And that, due to signedness of char (something that does not happen in asm). Quote:
Bug reports are there because you made mistakes and/or did not use the right tool (though often there is none available). Quote:
So often i wanted to do changes (in somebody else's code) and ended up with many compilation errors. Damned C code is fragile as a soap bubble (cpp is even more). Quote:
But in any case you're indeed locked in that loop because compiled code is never satisfying. Quote:
And no, high level languages aren't exactly readable. No language actually is. Take a random source in a random project on the net, chances are good it doesn't even say what it's supposed to achieve ! People trust HLLs too much for readability, a big mistake. I rather trust my comments. Quote:
Quote:
Quote:
Anyway, in all languages it's probably easier to just rewrite it all, so original language does not matter that much here. Quote:
First, you are mismatching complexity involved in writing the code (checking arguments or pointers) with overall complexity of the code once it is finished (which matters a lot more !). Second, as level of features of software raises, complexity also should ? No. It shouldn't. At least, not by big amounts. If it does, then there is something wrong in the design. This is why you'll never see me writing "complex" (or very big) software. The "me, i do big projects and you don't" looks more and more to me like an ego issue. |
|||||||||||||||
11 April 2022, 11:17 | #220 | |||||
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,355
|
Quote:
Have I said there was a language perfect for all tasks ? No. All i'm saying is that any task can be performed in asm (which is not true for all these HLLs), and that it's not as difficult as some pretend. Quote:
Quote:
It does not look very complicated. Quote:
Quote:
Well, vasm is still not doing it right for me as it does not have a regular global config file like phxass, which at least means larger command line to type. It is not only slower - it also uses significantly more memory, which sometimes means it simply can't do the job ! (Not to mention it crashed a few times on me, without a clear way to reproduce the problem.) Well, it is not that simple. I have maintained and ported enough code to know it is at best less difficult. |
|||||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Apollo 1240 missing Mach chip | Benfromnorway | MarketPlace | 3 | 01 June 2016 21:53 |
Apollo 1240@25mhz + 32mb Ram (Mach131 chip so can be upgraded to 060) | fitzsteve | MarketPlace | 4 | 16 August 2010 19:01 |
Gauging interest: Amiga 600HD, Apollo 620, 2MB Chip, 8MB Fast | chiark | MarketPlace | 9 | 25 November 2009 20:18 |
Wanted: MACH131 chip from Apollo 040 or 060 | 8bitbubsy | MarketPlace | 8 | 29 October 2009 15:55 |
Cedric and the lost scepture Demo/Preview-Version | mai | request.Old Rare Games | 3 | 28 March 2008 16:27 |
|
|