Apollo Maggie 3D Chip - Preview Demo

[Gorf]

Originally Posted by meynaf

So ok if you want, the inner workings of the emulator are discussed. And ? What does it change at the end ? What has bringed us there at first place already ?

Your claim/accusation Thor's answer was OT on this whole page.
It was not.
At the same time both of you were pretty OT regarding this specific thread.

I just tried to point out, that many subjects besides 68k architecture and assembler are in deed discussed here on EAB - so it was unfair to dismiss Thors's answer as generally OT .... especially while being not really on topic of this specific thread yourself the whole time.

[meynaf]

Originally Posted by Gorf

Your claim/accusation Thor's answer was OT on this whole page.
It was not.
At the same time both of you were pretty OT regarding this specific thread.

I just tried to point out, that many subjects besides 68k architecture and assembler are in deed discussed here on EAB - so it was unfair to dismiss Thors's answer as generally OT .... especially while being not really on topic of this specific thread yourself the whole time.

But you didn't say a thing when phx wrote "This is not the forum for professional software development" (in reply to Thor, too).

[Bruce Abbott]

Originally Posted by Promilus

And that's still rating 3x smaller than Visual Basic. Who is still developing in VB anyway? Also this index doesn't tell anything about number of applications made in that particular language.

And the most popular language according to TIOBE is... Python (+3.95% up from last year). This certainly supports your theory that people chose a language for convenience rather than performance. But Python? If that's the way 'modern' programming is going I want no part of it.

you seemed to have a problem with anyone talking how more efficient development is using HLL just because it saves YOUR TIME as a developer.

The last project I wrote in C was a nightmare. I had to upgrade the compiler just to get it to work at all, then lost the ability to use the simulator. I took me ages to figure out how to convert the data from bytes to bits (so it would fit in the available memory) whereas in assembler it would have been a doddle. Perhaps I should have written the program from scratch in assembler instead of 'saving time' by porting the C code from Windows.

[Don_Adan]

Originally Posted by Promilus

There's no shortage of x86 demos on their demoscene. Or 6502, or Z80.
And because asm is so great KK does Dread in C using VS Code and 68k cross compiler with WinUAE as test environment. At least that's what I saw during his presentations on YT. And he does on STOCK A500 something previously unimaginable (whether in asm or not!) So I guess coding in asm isn't a prerequisite to do something impressive on Amiga.


Ok ... so you want me to pay you for something - as you admitted - isn't your job but a hobby, done for fun, also that's the very thing you might be able to do to prove your point ... Yeah. Makes perfect sense.

I never stated that HLL were created to produce code which is faster than asm hand optimized code. It is made to make SOFTWARE DEVELOPMENT faster, easier and more efficient. And asm doesn't fit into that. That's why once processors became fast enough asm was thrown into a pit where it is still used only to verify what compiler outputs or work around some time-sensitive subroutines.

Yes, but in a few lines of code you can have application with GUI, using system clock, file operations, string operations, network access etc. etc. There's nothing asm coder can do to make those things any easier for him.


I don't have a problem with you using 68k asm for everything you do on amiga. It becomes a problem when you insist it's the best way to develop everything (on Amiga or whatever) because it produces smallest code and fastest code.

But You know that Dread using SMC? This game is written in C and ASM.

[Thomas Richter]

Originally Posted by Bruce Abbott

And the most popular language according to TIOBE is... Python (+3.95% up from last year). This certainly supports your theory that people chose a language for convenience rather than performance. But Python?

Yes, Python. Python can be very performing, indeed, but the actual code is in such case not run by python, but by your graphics card. All the deep learning/neural network programming mostly happens in python today as it has a strong library/framework support that helps you a lot taming the beasts. No, you most certainly don't want to program your GPU in assembly (that's probably not even supported as generations of GPUs change), but whether that's CUDA or Python does not make any difference as the end result is compiled to the corresponding cores on the card anyhow, and it's much much more convenient to do that in python than in any other language.

Originally Posted by Bruce Abbott

If that's the way 'modern' programming is going I want no part of it.

That's your choice to live in the past. It's a different type of fun experience, but yes, you have to learn something new.

Originally Posted by Bruce Abbott

The last project I wrote in C was a nightmare.

The same can be said to many assembler projects. Hard to update, hard to debug, hard to maintain. It's ok for tiny code, but it scales badly.

Originally Posted by Bruce Abbott

Perhaps I should have written the program from scratch in assembler instead of 'saving time' by porting the C code from Windows.

Perhaps you should have written the code in a portable way to begin with. The code I'm writing here (C++ not C) compiles fine on windows, linux and many other systems. Ok, granted there is a C++ compiler for them.

[coldacid]

Could we get a mod to split out all this argument into its own thread in a more appropriate place, so that this thread can get back ON topic?

[NovaCoder]

Originally Posted by coldacid

Could we get a mod to split out all this argument into its own thread in a more appropriate place, so that this thread can get back ON topic?

Anything to do with Vampire 'enhancements' are always going to stir up spirited debate here on EAB...

[Promilus]

Well, to be honest anything apollo-related was already discussed and that part has ended, this one is basically a rant about different CPU architectures, compilers and hll ... and how asm is better and faster at everything, from output code to project management

[Bruce Abbott]

Originally Posted by Promilus

Well, to be honest anything apollo-related was already discussed and that part has ended, this one is basically a rant about different CPU architectures, compilers and hll ... and how asm is better and faster at everything, from output code to project management

...on any platform, including neural networks running on high-end GPUs. Gotta stuff as much as possible into that straw man!

[Promilus]

I took me ages to figure out how to convert the data from bytes to bits (so it would fit in the available memory) whereas in assembler it would have been a doddle.

Well that actually tells more about your own skills than language itself. I find that argument quite amusing. Rather than convincing others that HLL is useless as YOU could do anything faster in asm it'd be more beneficial for YOU to at least try to learn a thing or two. I'm done with asm. Got plenty of it with Hitachi, Intel, Motorola and TI microcontrollers. Once C presence was well established in embedded applications there was really no need to go back to asm (unless - as I already mentioned - time critical subroutines which occurs less and less). You don't believe me? Search for job offers - embedded software engineers. See in how many C is required and in how many asm. And C is (outside embedded) declining language already. Everyone everywhere is wrong only Bruce and menaf are right...

[Mathesar]

Originally Posted by Promilus

I'm done with asm. Got plenty of it with Hitachi, Intel, Motorola and TI microcontrollers. Once C presence was well established in embedded applications there was really no need to go back to asm (unless - as I already mentioned - time critical subroutines which occurs less and less).

Hitachi! H8S by any chance? I actually liked that CPU a lot. 8 32bit register that could be reused as 16 16bit registers or 8 16bit registers + 16 8bit registers. Plenty of room thus to store your variables locally. Compact but usable instruction set. Couple that with single cycle execution for most instructions and very low power consumption for the time and you had a winner in my eyes.
I programmed a FIR filter once for it that ran quite fast. However the bulk of programming I did for the Hitachi was of course in C with an IAR compiler. (Got bitten by a nasty compiler feature/trick/oversight-on-my-part once where it would map a large struct across a 64K boundary in external memory. However, in the "small" memory model pointer arithmetic was done with 16bit integers.)

[meynaf]

Originally Posted by Promilus

Well that actually tells more about your own skills than language itself.

So you have to admit that asm is perfectly fine at least for some people. Didn't I tell somewhere something about having the right mindset ?

Originally Posted by Promilus

Rather than convincing others that HLL is useless as YOU could do anything faster in asm it'd be more beneficial for YOU to at least try to learn a thing or two.

Strawman again. We're not saying HLL is useless, it's you who are saying ASM is useless.

[Thomas Richter]

Look, which language you are going to pick is your business, but you will have to deal with the consequences of your decision. Asm as language means that you have projects that will small scale, hard to complete, hard to debug. It is not a very productive environment, and it leads to software that is typically never quite stable and often incomplete.

[Promilus]

@meynaf

So you have to admit that asm is perfectly fine at least for some people

I have never claimed otherwise. You approach the problem with the most efficient way for you. Doesn't mean that if someone worked for you it will work for everyone. When AVR (popular hobbyist MCU architecture, fairly cheap and more powerful than old 51) surfaced there weren't many good tools, tutorials etc. about C for those microcontrollers and libs were buggy. That's why most AVR users in late 90s used asm exclusively. Around 2010 there was already pretty solid IDE with AVRGCC compiler and by that time plenty of developers already switched to C due to growing and impressive code base. Later on situation was even more improved with emergence of Arduino. And while it eats up resources like crazy it did popularize small development boards. You might think "lol, I'd create asm code that in some cases is 1000x faster" and that'd be true. But be honest here - how much would it take you to develop something like ESPEasy in asm alone? Or MySensors?

it's you who are saying ASM is useless

No, I wrote it is hardly used nowadays. It doesn't mean it's useless. It means is not popular and it's usage (if there is any) is confined to specific tasks inside larger project. And even back in 90s Amiga developers struggled with asm that's why e.g. AMOS was created. And while most of those games are buggy and hardly optimized there are some nice games which wouldn't be developed otherwise. And there most likely wouldn't be that much ports from other platforms as well if there wasn't someone interested in C. There most likely wouldn't be OS 3.1.4 and 3.2, many communicators, browsers, media players.

@Mathesar - yes, H8 family. Neat design and ASM I was able to switch instantly after 8051.

@Thomas Richter - actually well written asm is rock solid. In any circumstances. While ever growing APIs, protocols, optimizations etc. in HLL makes in vulnerable to some undefined behaviors in certain situations (as you're not the one who wrote big chunks of the code - those were external libraries). So while old asm apps were buggy because were written sloppy nowadays app might crash or do somethings stupid even when written within guidelines. But that's only natural - with growing complexity code is made more vulnerable to something we can't predict or probe effectively during development stage. But... once problem is identified it is easier to narrow down to problematic code and make a patch.

[Thomas Richter]

Originally Posted by Promilus

@Thomas Richter - actually well written asm is rock solid. In any circumstances.

Err... Look, any well written code in any language is rock solid. But how much does it take to get there? That's where languages differ.



Even more so, persons that refuse to widen their horizon by refusing to looking at anything but asm are probably not those people that can write "rock solid code" in any language, probably not even assembler. That's just fanboy-ism, and that's not a good foundation for writing good code by choosing the right tools for the job.


Maybe the reason why those people cannot write high-language code is a lack of skills or knowledge, but not a deficiency of the high-level language.

Originally Posted by Promilus

While ever growing APIs, protocols, optimizations etc. in HLL makes in vulnerable to some undefined behaviors in certain situations (as you're not the one who wrote big chunks of the code - those were external libraries).

That goes to any any language. It is a matter of scaling: Large projects are large scale by definition, and require complex interactions with outside code parts. The question is now, which language is more suitable to deal with complexity, assembler or high-level languages that provide compile-time checks to help you detect interface protocol violoations.


The answer is not "write assembler", the answer is "avoid complexity". Unfortunately, depending on what you want to do, it is not always simple, or possible, to avoid complexity.

[meynaf]

Originally Posted by Thomas Richter

Look, which language you are going to pick is your business, but you will have to deal with the consequences of your decision. Asm as language means that you have projects that will small scale, hard to complete, hard to debug. It is not a very productive environment, and it leads to software that is typically never quite stable and often incomplete.

You are charging the language for something it is not responsible of.
And remember you too have to deal with the consequences of your decision. Like wasting 50-75% of your raw cpu power for nothing, making memory hogs, and ultimately software that has potential exploits (and many hidden bugs) because "high level" language did hide something that would have been otherwise obvious in asm.

Originally Posted by Promilus

@meynaf
I have never claimed otherwise. You approach the problem with the most efficient way for you. Doesn't mean that if someone worked for you it will work for everyone. When AVR (popular hobbyist MCU architecture, fairly cheap and more powerful than old 51) surfaced there weren't many good tools, tutorials etc. about C for those microcontrollers and libs were buggy. That's why most AVR users in late 90s used asm exclusively. Around 2010 there was already pretty solid IDE with AVRGCC compiler and by that time plenty of developers already switched to C due to growing and impressive code base. Later on situation was even more improved with emergence of Arduino. And while it eats up resources like crazy it did popularize small development boards. You might think "lol, I'd create asm code that in some cases is 1000x faster" and that'd be true.

Ok so we have no reason to disagree then

Originally Posted by Promilus

But be honest here - how much would it take you to develop something like ESPEasy in asm alone? Or MySensors?

Quite a lot of time, assuredly. But somewhat less (and certainly not more) than with C or any other similar language. Provided, of course, i don't have to do that on a bogus cpu.

Originally Posted by Promilus

No, I wrote it is hardly used nowadays. It doesn't mean it's useless. It means is not popular and it's usage (if there is any) is confined to specific tasks inside larger project. And even back in 90s Amiga developers struggled with asm that's why e.g. AMOS was created. And while most of those games are buggy and hardly optimized there are some nice games which wouldn't be developed otherwise.
<snip>
There most likely wouldn't be OS 3.1.4 and 3.2, many communicators, browsers, media players.

I haven't said otherwise either...
Yes it is more rare today than it used to be, but you have to admit the fact that mainstream machines having very poor asm does not help.

I am only telling you that every program can be done in asm and that for someone used to it, it's not as hard as it looks.
That not everyone can do it, that you can't do it, that ThoR can't do it, that it's an horror on most cpu families, does not change that fact.

Originally Posted by Promilus

And there most likely wouldn't be that much ports from other platforms as well if there wasn't someone interested in C.

I made many ports from other platforms, none of which involved C on my side (but did involve, otoh, lots of brain damaged compiler-generated horrors).
At least with ASM a port can be made without having the source code.

Originally Posted by Promilus

@Thomas Richter - actually well written asm is rock solid. In any circumstances. While ever growing APIs, protocols, optimizations etc. in HLL makes in vulnerable to some undefined behaviors in certain situations (as you're not the one who wrote big chunks of the code - those were external libraries). So while old asm apps were buggy because were written sloppy nowadays app might crash or do somethings stupid even when written within guidelines. But that's only natural - with growing complexity code is made more vulnerable to something we can't predict or probe effectively during development stage.

Not directed to me, but yes, you've understood here a big part of the problem.

Originally Posted by Thomas Richter

Err... Look, any well written code in any language is rock solid. But how much does it take to get there? That's where languages differ.

Not in every language - some are buggy by themselves - but that point is right.
However, of course, it takes less time in ASM to reach that point. Remember, ASM is "fail early and fail big" environment, where most HLL is "fail silently and keep going".

Originally Posted by Thomas Richter

Even more so, persons that refuse to widen their horizon by refusing to looking at anything but asm are probably not those people that can write "rock solid code" in any language, probably not even assembler. That's just fanboy-ism, and that's not a good foundation for writing good code by choosing the right tools for the job.

A now this is becoming preposterous.
I have written code for many platforms, with many languages. It ranges from Pic to C370, with everything in between including pc programs in cpp and web apps in .net. I've been involved in a team that had to build a whole ISP solution.
And i did that better than all those guys who didn't have asm knowledge.

Originally Posted by Thomas Richter

Maybe the reason why those people cannot write high-language code is a lack of skills or knowledge, but not a deficiency of the high-level language.

This argument can be returned against you quite easily. Just replace high-level by asm.

Originally Posted by Thomas Richter

That goes to any any language. It is a matter of scaling: Large projects are large scale by definition, and require complex interactions with outside code parts. The question is now, which language is more suitable to deal with complexity, assembler or high-level languages that provide compile-time checks to help you detect interface protocol violoations.

But again, maybe large projects are large more due to being poorly designed (and/or using the wrong tools) rather than what their inherent entropy involves.

Originally Posted by Thomas Richter

The answer is not "write assembler", the answer is "avoid complexity". Unfortunately, depending on what you want to do, it is not always simple, or possible, to avoid complexity.

But writing assembler is a way to avoid complexity

[Havie]

As a V1200 owner my concern is that we will be neglected going forward. For instance, it would be great to see Openlara running on a V2 but there has already been discussion about targeting V4 and Maggie to get the highest quality. Whereas an AGA version for fast Amigas would be more impressive and able to be used by all.

[Promilus]

@menaf

Quite a lot of time, assuredly. But somewhat less (and certainly not more) than with C or any other similar language. Provided, of course, i don't have to do that on a bogus cpu.

Sure. But the big question here isn't how fast YOU can write the same functionality in C but how fast average C developer can get ESPEasy-like functionality (node-node intercommunication through wifi, TCP/IP, MQTT protocol, drivers for plenty sensors, actuators, data logger, embedded scripting language, web gui and Over The Air upgrade tool) and in contrast how long would it take to average asm developer to do the same. I expect only honest answer at this one.

[Bruce Abbott]

Originally Posted by Promilus

Well that actually tells more about your own skills than language itself. I find that argument quite amusing. Rather than convincing others that HLL is useless as YOU could do anything faster in asm it'd be more beneficial for YOU to at least try to learn a thing or two.

I am not averse to 'learning a thing or two'. Here's a program I wrote for Windows XP, done in pure C without any 'frameworks' or GUI builders. I learned heaps about Win32 coding and thoroughly enjoyed it. There's no way I would have attempted it in x86 assembler, even though I could have. I mean, x86 assembly code sucks, and a modern PC is so powerful that speed and memory usage aren't an issue for an app like this.

OTOH, when it came to porting this 16 bit Windows program to an ATmega168 with only 16k ROM and 1k RAM, just getting the code to compile at all was a struggle.

And you can't seriously suggest that the code for this project should have been written in C rather than assembler, right?

I'm done with asm. Got plenty of it with Hitachi, Intel, Motorola and TI microcontrollers. Once C presence was well established in embedded applications there was really no need to go back to asm (unless - as I already mentioned - time critical subroutines which occurs less and less). You don't believe me? Search for job offers - embedded software engineers. See in how many C is required and in how many asm.

The straw keeps piling higher.

This website is the English Amiga Board, where we talk about our hobby of playing with machines that traditionally have been programmed in assembler when the best performance was desired. We aren't doing it for a living, so we don't have to bang out code as quickly as possible or pass it on to others who don't have our knowledge. Like many hobbies, the enjoyment is in the doing - so we don't care if it takes longer or is more challenging. That's the nature of a hobby, and nobody can tell us it isn't right.

And C is (outside embedded) declining language already.

Yes. Python is 'it' now, so anyone programming in a 'lesser' language (outside embedded) is wrong. Everybody coding for the Amiga must hereby translate all their 68k code to Python to avoid being laughed at for 'living in the past'.

Everyone everywhere is wrong only Bruce and menaf are right...

I won't speak for meynaf, but as you can see I am not against using other languages. I even tried Python (not a pleasant experience on my Amiga - but hey, Python!). I dare you to show me why I should throw away my assembler and rewrite all my Amiga stuff in Python.

[Promilus]

where we talk about our hobby of playing with machines that traditionally have been programmed in assembler when the best performance was desired

Yes. And those machines traditionally have no or little fast ram and traditionally had slow 68000 or 68020. But then they got better. More games upgraded from NDOS, register banging to OS ans system functions. And E or C or Basic instead of asm. It's not "less amiga" to write in C instead of asm.

Everybody coding for the Amiga must hereby translate all their 68k code to Python

Oh, and where did I state anything like that? All I ever wrote is using HLL makes development easier, faster, code portable, better manageable and porting stuff from PC (either based on original source code or opensource implementation of game engine) is best proof of that. And you are arguing with thesis I never presented. And here's best example

I dare you to show me why I should throw away my assembler and rewrite all my Amiga stuff in Python

Where in the world did I wrote "go ahead move your code base to HLL already"? Nowhere. So cut that crap!