English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 28 August 2015, 20:03   #361
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by idrougge View Post
For the same reason, I use mostly gosubs in my current Blitz project, instead of the tidier functions and statements. When I was programming in AMOS, I only used procedures, but Blitz's (otherwise horrible) manual was friendly enough to suggest the use of gosubs in the chapter on optimisations.
i'm surprised at Blitz, i'd have expected it would be better than that.
Mrs Beanbag is offline  
AdSense AdSense  
Old 28 August 2015, 20:39   #362
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 862
I suppose that functional programming (or using procedures/functions imperatively) will always be slower than GOTO/GOSUB but we now have CPUs fast enough for it not to matter. Go back down to a 7MHz miggy though, and the difference in performance might actually be large enough to be detrimental.

D.
Dunny is online now  
Old 28 August 2015, 21:31   #363
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
i really don't think so, if a function has no parameters or return values (which is all the behaviour of GOSUB anyway) it shouldn't make a difference, with a well-designed compiler.
Mrs Beanbag is offline  
Old 29 August 2015, 00:16   #364
Dunny
Registered User

Dunny's Avatar
 
Join Date: Aug 2006
Location: Scunthorpe/United Kingdom
Posts: 862
Quote:
Originally Posted by Mrs Beanbag View Post
i really don't think so, if a function has no parameters or return values (which is all the behaviour of GOSUB anyway) it shouldn't make a difference, with a well-designed compiler.
How many well-designed compilers do we have for the Amiga? I've not kept up with that sort of thing since moving the PC for my coding needs many years ago, so am genuinely interested.

That said, I do agree - a decent optimising compiler will eliminate stack frames where necessary, load registers when possible for function calls and inline if it's of any benefit... but I don't know if any current (or previous) compilers actually have this sort of optimising technology. It would seem that neither the Blitz nor Amos compilers do.

D.
Dunny is online now  
Old 29 August 2015, 02:58   #365
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,070
Quote:
Originally Posted by Mrs Beanbag View Post
i'm surprised at Blitz, i'd have expected it would be better than that.
Well, so was I, but I'm not convinced that other languages have function calls for free.
idrougge is offline  
Old 29 August 2015, 03:00   #366
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,070
Quote:
Originally Posted by Mrs Beanbag View Post
i really don't think so, if a function has no parameters or return values (which is all the behaviour of GOSUB anyway) it shouldn't make a difference, with a well-designed compiler.
I actually think you are on to something here. I have read that a Blitz function that has no private variables is just as fast as a gosub.
idrougge is offline  
Old 29 August 2015, 03:58   #367
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,012
Quote:
Originally Posted by Mrs Beanbag View Post
i really don't think so, if a function has no parameters or return values (which is all the behaviour of GOSUB anyway) it shouldn't make a difference, with a well-designed compiler.
Behold, you yet-not-fully-learned kittens in the arts of code, this creature here speaks the truth!

Even some of the compilers of the old days (gcc) were able to generate efficient function calls. Of course these would not be as great as assembly-and-love-and-effort-made ones but still fast enough to not have a major influence on execution speed.
And if they did not, there was still popt, the nice peephole optimizer of Samuel Devulder which was capable of removing much of the fluff of not-so-lean function calls.

Quote:
Originally Posted by Dunny View Post
How many well-designed compilers do we have for the Amiga? I've not kept up with that sort of thing since moving the PC for my coding needs many years ago, so am genuinely interested.[/url]
We haz a lot!
vbcc for one, does generate good function calls code, gcc is not too bad, and I'll bet that LLVM will too when the 68k back end will be finished.


Quote:
Originally Posted by Dunny View Post
That said, I do agree - a decent optimising compiler will eliminate stack frames where necessary, load registers when possible for function calls and inline if it's of any benefit... but I don't know if any current (or previous) compilers actually have this sort of optimising technology. It would seem that neither the Blitz nor Amos compilers do.
Look no further than vbcc as I mentioned above.

Quote:
Originally Posted by idrougge View Post
Well, so was I, but I'm not convinced that other languages have function calls for free.
Function calls are very cheap in the 68k world unless the interpreter/compiler is doing something very wrong. Early C compilers (and some late as well) on the Amiga tended to use LINK/UNLINK instructions for function calls which can have their use but are generally very slow and useless but this era is over.

As Mrs Beanbag pointed with her usual reasonableness, there is close to no conceptual difference between gosub and a function call (especially if you do not pass parameters) so the only explanation for Blitz Basic behaviour is well... that it is likely very ill conceived.

Quote:
Originally Posted by idrougge View Post
I actually think you are on to something here. I have read that a Blitz function that has no private variables is just as fast as a gosub.
They must have been smoking kangaroos's fur when they wrote this stuff.

I wish there was an IDE on the Amiga configurable enough to work straight out of the box with external languages (AmigaE, C, Arexx, etc.) because I'm fairly convinced that the reason AMOS and BlitzBasic still have so many adepts is that they provide an integrated development environment which helps non-experts feel secure enough which in turns allows them to experiment.

Having to learn how to configure and tie several non connected pieces together before one can start coding a simple hello world is indeed understandably dissuasive.
ReadOnlyCat is offline  
Old 29 August 2015, 04:32   #368
beezle
Banned

 
Join Date: May 2015
Location: Australia
Posts: 67
I can't help but notice the trend of people being quickly dismissive of things they're not particularly familiar with here.
Yes, there's some areas where a fish is a fish, but judgements are being passed and opinions being made based on what people know, while disregarding what they don't.

End results are what matters, and as such it seems crazy to write off, for example, blitz, which has has been used to create pretty high quality software many times in the past.

Just an observation really.
beezle is offline  
Old 29 August 2015, 08:10   #369
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,012
Quote:
Originally Posted by beezle View Post
I can't help but notice the trend of people being quickly dismissive of things they're not particularly familiar with here.
Yes, there's some areas where a fish is a fish, but judgements are being passed and opinions being made based on what people know, while disregarding what they don't.

End results are what matters, and as such it seems crazy to write off, for example, blitz, which has has been used to create pretty high quality software many times in the past.
As seducing as your argument may sound, it does not support your conclusion:
  • Blitz: used to create many high quality software on the Amiga.
  • C and Assembly: used to create 99% of high quality software on the Amiga.
So, yes, _some_ high quality programs were made in Blitz, but _most_ high quality programs were not.
_Some_ good games were made in Blitz (I know none but I'm sure there are), but _most_ great games were not made with Blitz or AMOS.

From a purely statistical point of view if end results matter, then not choosing Blitz seems much safer.

But from a technical point of view, if Blitz was so suitable for writing games, it would have been more used. Experienced assembly and C programmers would have had no issue to adapt to it (because frankly it's much simpler than both) if it really had made them more productive but the reason for these statistics is that BASICs are in the general case not suited to build more than moderately complex programs. The "many" you are talking about are exceptions, not the norm.

I might sound quickly dismissive, but my opinion of BASIC was forged over years of coding experience, about 30 total, of which 17 professionally, in about 15 languages, I did not come to think bad of BASIC overnight.
As for familiarity, I breathed BASIC from 13 to 18 on different computers (with brief incursions into assembly). I was a great GFA Basic fan which I bought along with its compiler and used it extensively to prototype a lot of ideas on my Amiga. Before I knew better, I used to love BASIC.

BASICs are great to learn the rudiments of code, but that's where it ends as well. They do not provide abstractions which are absolutely necessary for programming any moderately complex program. And any interesting game is necessarily a moderately complex program.

It says a lot that even though assembly language provides even less abstractions than BASIC and requires way more effort, it is still more suitable to create games on the Amiga. The few advantages that BASIC has over assembly are not enough to compensate for its structural deficiencies or its bad implementation.

Regarding the GOSUB issue, let me explain why I made the hypothesis that the Blitz team was smoking weird animal substances:

In computing theory, GOSUB and functions are fundamentally the same abstraction: there are no practical and theoretical reasons to treat them differently, regardless of whether they have variables or not, and a compiler will produce the same assembly code for both. This is the 101 of compiler engineering and is taught in computing science classes at the university and the only explanation for a difference is that Blitz is badly implemented, really badly because frankly this is a long solved issue in computing science.
The fact that variables cause a speed difference also smells strongly of bad design. Local variables are handled using the processor stack and they do not cause any sensible additional cost in both cases. Incrementing the stack pointer is really cheap and would make a difference only for extremely short functions.

Now, maybe I was wrong about the type of animal they used for the smoking but I'm sure that they were not as lucid as they should have been when they designed the compiler.

But more importantly, what do you think will make your program more efficient?
A better structure, better abstractions, better algorithms or choosing GOSUB over functions/procedures?
I'm sure you would say it is the former but these kinds of issues are symptomatic of BASICs: they are so deficient that they encourage local optimization over program and data structure. The speed of your program should depend on your code structure, not on using keyword X instead of keyword Y otherwise it means that the machinery of the language consumes more resources than your own code!

I am sorry if I gave you the impression that I had some irrational and impulsive dislike of Blitz but despite what you say I did give very technical explanations in my initial post, I hope nevertheless that I cleared away the impression that it was lack of familiarity with Blitz which drove my opinion. I used to think a lot of good from AMOS and Blitz but that was before I learned better.

BASIC is like sugar: approachable, easy and sweet. But if you have any long term plans you should get away from it.

May a million kittens hug you tenderly!
(Not at the same time preferably.)

Last edited by ReadOnlyCat; 29 August 2015 at 08:39. Reason: Reformulated slightly.
ReadOnlyCat is offline  
Old 29 August 2015, 08:53   #370
beezle
Banned

 
Join Date: May 2015
Location: Australia
Posts: 67
Not to get drawn into any "I've been doing this for x amount of time" argument, but I'm pretty well versed in the theory. I started programming in 1980 on a Tandy coco1 and have used many languages on many machines since.
I specifically mentioned blitz, as it has been shown to be capable of good results. In fact Andrew Braybrook has even suggested 2nd to asm blitz is the best language on the Amiga for producing fast moving arcade style games.
Gloom and Skid marks are good examples, even if they do use some inline asm.

Why more software wasn't produced with it is probably more to do with portability and paradigms than capabilities. Even I use c more, despite liking blitz. My observation was exactly that. An observation. Not any sort of loyalty or particular fondness for basic variants.

AMOS is also a good example of judging a language by end results, however I opted to use blitz as an example, because positive end results resonate my point better than negative ones (ie. Amos, while fun, doesn't typically produce good results).

Last edited by beezle; 29 August 2015 at 09:03.
beezle is offline  
Old 29 August 2015, 18:24   #371
4mat_
Demoscene musician
4mat_'s Avatar
 
Join Date: May 2010
Location: UK
Posts: 51
Speaking as a freelancer back then, by the end of 1992 Amiga-specific work was very thin on the ground and pretty much dead by the end of 1993. It was still being used to prototype ideas for consoles, and in the art/sound departments, but as a going concern, no. So any language released after that point was going to have a tough time. I do remember doing the music for one Blitz project (edit: not Super Tennis, some similar name) but that got canned. (it was on the cover of a very late Amiga Power iirc)

Personally I'm quite a big fan of the Blitz range on PC, I still use Max to write quick dev tools because it's so fast to get graphical utilities made within a few lines. (instant access to gfx screen, input, i/o) I did use the follow-up Monkey for a year or so (wrote a couple of engines for Flash/HTML5) but switched over to Unity in the last year.

Last edited by 4mat_; 29 August 2015 at 20:36.
4mat_ is offline  
Old 29 August 2015, 18:29   #372
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,776
If id have known it was Fishy I wouldnt have bothered - you dont know how many times this guys says hes going to convert this game and that game ......
Thanks
.
.
.
.
http://www.amiga.org/forums/showthre...787#post768787

Last edited by Retro1234; 29 August 2015 at 23:13. Reason: Silly Fishy ;)
Retro1234 is offline  
Old 29 August 2015, 19:47   #373
beezle
Banned

 
Join Date: May 2015
Location: Australia
Posts: 67
Not a bad start, but really its not doing much. Just a simple tile based scroller. Very jerky too. I'm going to guess you're updating your tiles a row at a time? It shows when anything else is happening other than the scrolling. With some optimizing, even simply drawing a single tile at a time per pixel scrolled you can get smoother results, even on a bog standard a500/a600. You can also skip rendering a tile when the area of graphics is blank, which with something like Mario can be upwards of 1/3rd of the time.

Check out final fight aga as a recent blitz example, or a brief bit of my half finished "Dragon's Lair AGA" port:
[ Show youtube player ]

By the way, Reality is a piece of crap
If you think its quality then we clearly have different ideas of the definition of the word "quality".
It screams, "look at me, I'm made with AMOS"

Last edited by beezle; 29 August 2015 at 20:04.
beezle is offline  
Old 29 August 2015, 20:05   #374
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 915
Send a message via Yahoo to Samurai_Crow
AmosPro has a bad compiler but the programming environment is quite handy. As for the tile scrolling, I'll work on that also with the TOME replacement I'm going to work on once I have written Tilemap.library in C.
Samurai_Crow is offline  
Old 30 August 2015, 04:26   #375
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,070
Quote:
Originally Posted by ReadOnlyCat View Post
As Mrs Beanbag pointed with her usual reasonableness, there is close to no conceptual difference between gosub and a function call (especially if you do not pass parameters) so the only explanation for Blitz Basic behaviour is well... that it is likely very ill conceived.
Possibly. The source code is available and still updated in the shape of AmiBlitz, so whoever can read "the ugliest assembly code ever written" is free to find out what Blitz does wrong.

Quote:
Originally Posted by ReadOnlyCat
I wish there was an IDE on the Amiga configurable enough to work straight out of the box with external languages (AmigaE, C, Arexx, etc.) because I'm fairly convinced that the reason AMOS and BlitzBasic still have so many adepts is that they provide an integrated development environment which helps non-experts feel secure enough which in turns allows them to experiment.
Don't we all?
Only, Blitz coders have wished since 1992 that the environment was a bit less integrated, since the compiler is tied to the abysmal Ted editor. It's not as bad as Emacs or Vi, but it's still a shitty editor.
AMOS, on the other hand, has an integrated environment that looks good to this day.
idrougge is offline  
Old 30 August 2015, 06:29   #376
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,012
Quote:
Originally Posted by idrougge View Post
Possibly. The source code is available and still updated in the shape of AmiBlitz, so whoever can read "the ugliest assembly code ever written" is free to find out what Blitz does wrong.
Oh, I was really out of the woods for too long, I did not know the source was available. And no, I won't be touching it with a ten meters pole.

Quote:
Originally Posted by idrougge View Post
Don't we all?
Only, Blitz coders have wished since 1992 that the environment was a bit less integrated, since the compiler is tied to the abysmal Ted editor. It's not as bad as Emacs or Vi, but it's still a shitty editor.
AMOS, on the other hand, has an integrated environment that looks good to this day.
Well, I quite like Emacs! Even though I use SublimeText these days to edit my personal code.

While we are talking about IDEs and Amiga development, I must mention again to any wannabee Amiga coder the great Toolchain that Hannibal from Lemon did on Windows:
http://www.pouet.net/prod.php?which=65625 (click the download link on the right).

It works with Visual Studio and the included examples allow to create a boot demo and launch it as a boot disk inside WinUAE with the press of a key. Reaaaaaally neat.

It is still a bit terse for a complete noob but for any experienced coders it should be a god send. If someone decided to make tutorial videos with it maybe we would have a chance to dissuade people from using Amos or Blitz.
(It uses vbcc and vasm so it supports C and assembly straight out of the box.)

Quote:
Originally Posted by beezle View Post
Gloom and Skid marks are good examples, even if they do use some inline asm.
Ah! I had forgotten Skid Marks was written using Blitz, thanks for pointing it out. It's an example of a fantastic game made with the language indeed but even a few example do not make a trend.
I persist in thinking that you have to be a good programmer in the first place to make anything good in Blitz, because as a novice you will not have enough background to understand where and why it is innefficient nor work around it without compromising your program's structure.

Quote:
Originally Posted by beezle View Post
Why more software wasn't produced with it is probably more to do with portability and paradigms than capabilities.
This is very possible, my point is that newcomers should avoid Blitz if they want to acquire good coding habits and grow as coders. As you said it, the language as a proven track record of allowing great programs to be conceived but that does not mean it is suited to the EAB roaming bunnies who want to learn what code is all about and try to make their own games.

(This said, I must also say I am not convinced that C would be the best starting language for a new coder but I still think it's better than a BASIC.)

Last edited by TCD; 30 August 2015 at 07:49. Reason: Back-to-back posts merged.
ReadOnlyCat is offline  
Old 30 August 2015, 18:12   #377
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
i really would prefer to be able to use a text editor of my choice to write programs for the language of my choice, Devpac's editor is fairly good i use that for everything texty these days (on Amiga).

I would like C++ on Amiga but apparently it is quite resource-heavy? not sure why

Last edited by Mrs Beanbag; 30 August 2015 at 18:18.
Mrs Beanbag is offline  
Old 30 August 2015, 20:00   #378
Megol
Registered User

Megol's Avatar
 
Join Date: May 2014
Location: inside the emulator
Posts: 253
Quote:
Originally Posted by idrougge View Post
Well, so was I, but I'm not convinced that other languages have function calls for free.
Well... Forth can get very close to free as functions are comparable to gosub statements. OTOH most Forth systems aren't using compilers and emulating a stack architecture on a register machine have some overheads. OTTH (don't we all have a third hand? ;P) a good Forth interpreter can be competitive with a bad compiler for some normal languages.

Edit: Here bad compiler = for example a compiler targeting a register machine that uses a stack based model and a pattern matching code generator.

Quote:
Originally Posted by Dunny View Post
How many well-designed compilers do we have for the Amiga? I've not kept up with that sort of thing since moving the PC for my coding needs many years ago, so am genuinely interested.

That said, I do agree - a decent optimising compiler will eliminate stack frames where necessary, load registers when possible for function calls and inline if it's of any benefit... but I don't know if any current (or previous) compilers actually have this sort of optimising technology. It would seem that neither the Blitz nor Amos compilers do.
I guess we are talking about BASIC compilers? Otherwise e.g. VBCC seems to optimize well in my limited experience.

Last edited by Megol; 30 August 2015 at 20:15.
Megol is offline  
Old 30 August 2015, 20:56   #379
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
putting a few local variables and/or parameters on the stack really shouldn't be a big deal anyway, but my plan is to include with my compiler an option to output as ASM source so you can optimise manually at will.
Mrs Beanbag is offline  
Old 30 August 2015, 21:01   #380
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 915
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by Mrs Beanbag View Post
i really would prefer to be able to use a text editor of my choice to write programs for the language of my choice, Devpac's editor is fairly good i use that for everything texty these days (on Amiga).

I would like C++ on Amiga but apparently it is quite resource-heavy? not sure why
The meta-programming capabilities of deeply nested templates will quickly exhaust the meager amount of memory of a 68k Amiga, even fully expanded. I was hopeful that ChrisH would get type-safe macros (comparable to generics) and other stuff implemented in PortablE using only a C compiler as a backend. He seems to have lost some momentum as of late though.

Quote:
Originally Posted by Megol View Post
Well... Forth can get very close to free as functions are comparable to gosub statements. OTOH most Forth systems aren't using compilers and emulating a stack architecture on a register machine have some overheads. OTTH (don't we all have a third hand? ;P) a good Forth interpreter can be competitive with a bad compiler for some normal languages.

Edit: Here bad compiler = for example a compiler targeting a register machine that uses a stack based model and a pattern matching code generator.



I guess we are talking about BASIC compilers? Otherwise e.g. VBCC seems to optimize well in my limited experience.
Early implementations of LLVM had a Forth-like language called "Stacker" bundled with it but its author moved on and it quickly became unmaintained. There is a 68k backend in the works but the ones working on it have other concerns right now. The optimizer for the LLVM intermediate representation is nearly exhaustive in its implementation.

Still, though heavy, LLVM can be made more modular than other compilers due to its library-based design. It's a matter of making all the libraries not load in until they are needed and unload when they are done (though the first step is making a cross-compiler from an already-supported OS). Thus it is possible to make it run under AROS using its OOP.library (included in the kernel) to implement the C++ runtimes known collectively as LibC++. I'm afraid it will be a bit much for OS3 to chew on though, unless some hybrid emerges like AfaOS incorporates the absent features of any full version of AROS. It seems there's plenty to do and few people to do it.
Samurai_Crow 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
What is the technically most impressive A500 game? mc68060 Amiga scene 67 03 June 2015 23:32
The Tales of Grupp - Another impressive homebrew ZX Spectrum title! Neil79 Retrogaming General Discussion 3 24 February 2015 20:19
New One Of "Homebrew" 68k Amiga Magazine Idea fishyfish Retrogaming General Discussion 6 16 April 2013 09:57
Impressive and Amazing PD Software! Any thoughts? hamster Retrogaming General Discussion 0 18 July 2004 02:42

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 00:21.


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