Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bruceuncle]

Aieee!  What did you put in those two wardrobes and old couch apart from the butane bottle MadAngus?  Bonfire going great!   

I agree with most of what you've posted MadAngus.
Above all, there has to be stability in the core product, otherwise the whole concept of AMOS's flexible extension model falls in a heap.  That's what I meant by avoiding the 'DLL Hell' experiences in the earlier WIntel environments.  Whatever we do should not break these current AMOS Pro abilities:

• Supports current code in AMOS Pro, AMOS The Creator, Easy AMOS in the same way that the AMOS Compiler is supposed to.  A lot of effort obviously went into making that work and it's a good model from what I've seen so far.
• Supports both the 1.3 and 2.x¹ extension formats.  Again the model is good.
• The Compiler also supports all those formats.  (In theory.  However, it's also obviously got some problems  before it does what it was intended to.)
• Provides a stable base with known and predictable outcomes for programmers.  Now up until this point in time, AMOS Pro is stable in that there's been no further development.  That's one of its charms.  "That bug one found yesterday is still there today because there's no change happening.  So one works around it and one's code will still work tomorrow."  As big-brother as it may first appear, I strongly vote/recommend/plead for some 'official' versioning to avoid this.  I called it 'approved' in the previous post.

¹ - As far as I can tell from the various patches, etc that I've looked at, V2.0 is what we're talking about.  The Compiler mentions 2.x simply because they really did get the latest version into release.  Then there were no more.  I suspect that by calling it 2.x there they avoided having to revise the (then) printed docs.  (We take the ability to easily modify and re-distribute electronic docs these days a bit too much for granted  .)  I've found variants but they're all 'patched'.  That is the whole slab is identical to the original with a few very small changes written in situ without disturbing the original offsets, etc.  They have to be that way because otherwise, without access to the sources, the whole code chunk would fall in a heap.  They may be useful bug fixes (I haven't looked yet - I'm still up to my neck with other doc stuff, which I think essential before we do anything).  Anyway, V2.0 is V2.x etc.  I'm happy to go with V2.0 as it suggests a more constuctive versioning.

If by reverse engineer you mean write from scratch equivalent functions, then yes. However if this means Resourcing other code to derive the functionality and code, then absolutely not, for copyright reasons.

Ever since I were a wee naive lad learning COBOL  I've learnt to program from examples.  Even back then, I would pour over other people's program listings absorbing good and novel techniques and best practice.  I've been the same in all other programming environments since (no, I haven't got any friends  ).  I'm currently re-learning both 68k asm and AMOS.  I've grabbed all available source code and poured over it.  I've used Resource to get into code for which I've got no source.  Yes, the functionality and ideas I will plagiarise but not the code.  I can usually improve that  .
Anyway, fear not.  Anything I do myself will always be submitted through you guys for approval (maybe consider yourselves appointed as official custodians of 'approved' AMOS stuff?). 

Completely disagree. On the basis that there will probably be a significant list of feature requests from users. Many of these will be file format support requests, but you simply need to look at the Blitz variants to see were the development requests could go.

I agree with your right to disagree and disagree in turn  .  The AMOS Pro Extension model is fine.  There is nothing that you could do in the core that you can't do functionally with an appropriate extension except change the Editor and Monitor.  All other tools are AMOS progs and the same comment applies.  AMOS is AMOSPro.Lib and the other standard Libs in the release.  It was smart thinking for them to disengage the Editor's restrictions (640 width Hires screen with fixed toolbars, etc) from the language itself.  V2.0 did that and managed to retain backward source code compatibility with the other two products.
This requires a bit more explanation as I think it's something we have to acknowledge as inviolate.  Its tied in with this:

bruceuncle wrote:
Stage4:     AMOS Pro V3.0 for AGA and fully documented.

MadAngus wrote:
Keep as an extension until the AGA chipset is fully understood and full compatibility and functionality has been implemented

Having successfully decoupled the Editor and Monitor from the language, what next?  I strongly suspect that the intention was to go AGA by just changing the Editor and Monitor to operate at either AGA full-screen resolutions or as a resizable window.  So I may be completely wrong as I'm relying on intuition rather than facts, but I think we'll find the same thing.  That's why I speculate that we'd end up with two final products - V2.xx for non-AGA and V3.xx for AGA.  There's no technical reason why they couldn't share the same Libs including AMPOSPro.lib.  An AMOSPro_AGA.Lib would also work with both as long as developers in V2.xx didn't mind a 640x256 environment to work in  .

One feature I would like to see implemented is a new standard Amiga interface that worked within a window on the workbench.

Agreed - see above.

I won't waste space by quoting all that good stuff at the bottom of your post.  I'm all for it.  Managing it would be a nightmare  .

Now back to the stuff I'm supposed to be doing which needs to be completed before any of this could start anyway.  I'm still very happy. 

[SamuraiCrow]

Wow!  I'm impressed!  This is excellent news!

Sorry I've been away so long... especially after hearing this!

Since I've been gone I've had a programming job lined up and lost it.  I'm now working at a major retail store chain by unloading boxes and pulling palettes around.

If there's any hope of making the compiler optimize code better let me know.  That was always one of the shortcomings of Amos code.  I have heard that AmosPro does bit-shift optimization of multiplies but not much else.

Is there much to the AmosPro code generator?

[Sidewinder]

My my.  This is excellent news!

I guess now I can shelve my plans to write a new AMOS Pro interpreter and compiler in C.

[MadAngus]

Aieee!  What did you put in those two wardrobes and old couch apart from the butane bottle MadAngus?  Bonfire going great!   

Some lighter fuel, a few illegal bangers and the proverbial two gallons of petrol in a container, unopened, which hasn't exploded yet. I'm actually looking forward to some heated debate on this. Choose your weapons, my favorite is my enginneers hammer whom I have named, Meaty-Beaty-Big-And-Bouncy The IV, of course the classic half brick is also a good option.

I would like to get one thing out of the way first, and that's who is the DE-facto project lead on this.

Unless there is any objections, I nominate bruceuncle (already volunteered) as project lead. Personally, I simply do not have the programming skills to take this role on.

As project lead, bruceuncle would have/make the final decisions on any project management processes, code implementations strategies etc. Of course final decisions would be after due diligence with the community. I say this because management committee voting systems will delay and scupper this project as is the case with many other open-source projects.

What I want and believe is needed is someone who will say, OK debate is over, here is the pros and the cons and here is the decision. A benevolent tyrant system, is that OK with you my Lord Vetinari.

Now back to the stuff I'm supposed to be doing which needs to be completed before any of this could start anyway.  I'm still very happy. 

I will re-emphasise what I have previously stated. This discussion will take place over the next year. Yes there is much to be done before the redevelopment is begun in earnest, but we do want and need as many opinions as possible to get a feel for the desires of the community. I don't know who earnest is, never met him, so don't ask.

Stupid questions and bad ideas are most welcome. As long as the questions/ideas are related to the development of AMOSPro 3.x.
Any questions such as "What is the meaning of life", should be asked in a seperate thread.

I'm puting forward the suggestion that we use  "AMOSPro 3.x" as the projects working title.

Wow!  I'm impressed!  This is excellent news!

Sorry I've been away so long... especially after hearing this!

Since I've been gone I've had a programming job lined up and lost it.  I'm now working at a major retail store chain by unloading boxes and pulling palettes around.

If there's any hope of making the compiler optimize code better let me know.  That was always one of the shortcomings of Amos code.  I have heard that AmosPro does bit-shift optimization of multiplies but not much else.

Is there much to the AmosPro code generator?

Sorry to here about the job not happening . Good that you still have work as I can't get a damn thing.

When the source code is uploaded, it can then be studied in detail and the answers to your questions will no doubt become apparent. These questions can be added to the list of need to knows.

My my.  This is excellent news!

I guess now I can shelve my plans to write a new AMOS Pro interpreter and compiler in C.

It would be of significant benefit to this project if you signed up as a core developer.

SamuraiCrow, Hungry Horace, Spellcoder, FOL, and everyone else, if you want to volunteer and signup for roles or even a suasage-ona-stick, it would be great to have you. You could sign up to a role as interested but not yet committed.

There's, Documenter, core developer, contributing developer, project manager, website designer, beta testing, the man with the big stick (Project Lead) and any other anthropomorphic personifications that you may think appropriate.

I won't waste space by quoting all that good stuff at the bottom of your post.  I'm all for it. Managing it would be a nightmare  .

True, volunteers to take up certain roles would be required.

As for a project website as apposed to a forum, that should be no problem as I'm sure FOL will be more than happy to host it. It would also make sense to have the project website here with the forum along side all the other AMOS stuff that's here.

We can argue about the design of the website here aswell.  
Com'on ahe'd, if ye fink yor 'ard enough

All arguments and fighting will follow the Dimac rules of engagement. Anybody below a Fifth Level Master of Dimac should be polite. Please mind your Klatchian when posting.

Additional debate topics:
Language used, stick with 68k assy or port to c.
Could any of the xAmos code be used.
Should development of implementations be designed to be portable so that xAmos can make use of them.

Point of note:
Do not shy away from big ideas or suggestions, these can be achieved through milestone plans. Also the project will not get sidetracked or swamped by clever ideas. The milestone management system or whatever is in place should make sure that small steps from the base code is followed.

[Hungry Horace]

cool discussion.

Couple of minor comments to chip-in if i may?

You guys talk about implementation of improvement, tied into 'approved' extensions.

Where do you stand with regards to extension commands that duplicate (but are more efficient) AMOS commands?

For example.... AMOS  has a 'RND' command, but this is replaced by AMCAF's 'QRND' in practical usage.

Now... In your opinion, with the proposed development programme...

- Does AMOS 3.0 (hypothetically)  support both commands?   
- Does it recognise 'QRND' even without AMCAF loaded-in, and operate with it's own "new" faster 'RND' command?
- Does the user have to remove QRND from his code and re-write it as RND?
- Is the new, faster AMOS 3.0 RND code based on resources AMCAF code, or is it possible to have the AMCAF source released and fully integrated into AMOS?
- Does someone have to write new, faster, RND code from scratch???

You get where I am going with this, I am sure!! Just throwing it out there ...


Although AGA is the great potential benefit of a source release, I would be equally (maybe more) supportive of the development in terms of final-product output speed... more efficiently produced code.  BLITZ has been described by some people as jsut a clever set of ASM Macros.... and thus why it produces good, fast, programmes... why shouldnt AMOS3.0  be like this, but with the commands and interface we all know and love? 

Wouldn't you love to just re-compile your old AMOS code in a new version and suddenly find it so much faster?

Wouldn't you love to not need to scour through optimisation 'tips' and just get on with writing your programs? For example, I am constantly frustrated by using GOSUBs where i could/should be using nice tidy procedures... sometimes only 1 or 2 lines long!

I happy to help out in development where I can, but i imagine it would mostly be the testing side, as I am working on (another) electrical engineering qualification over the next two years.... not really much time to program ASM!

p.s. my view is Amiga Classic, and ASM output should alway be the 'core' ... the 'heart' of AMOS... with other implementations (C etc) as happy (and now easier?) by-products.... but that's a personal opinion.

Anyway....

IF AGA = TRUE THEN GOSUB PAAAAARTY! 

[MadAngus]

Where do you stand with regards to extension commands that duplicate (but are more efficient) AMOS commands?

If possible integrate them. (see below for more detail...)

For example.... AMOS  has a 'RND' command, but this is replaced by AMCAF's 'QRND' in practical usage.

Now... In your opinion, with the proposed development programme...

- Does AMOS 3.0 (hypothetically)  support both commands? 
- Does it recognise 'QRND' even without AMCAF loaded-in, and operate with it's own "new" faster 'RND' command?
- Does the user have to remove QRND from his code and re-write it as RND?
- Is the new, faster AMOS 3.0 RND code based on resources AMCAF code, or is it possible to have the AMCAF source released and fully integrated into AMOS?
- Does someone have to write new, faster, RND code from scratch???

You get where I am going with this, I am sure!! Just throwing it out there ...

All original commands should remain for compatibility to older code, if they could be optimised without braking compatibility, I do not see why not.

AMCAF is GPL, which would mean the entire AMOSPro would have to be converted to GPL. Linking is one way with the GPL, you cannot link from any other licenced code to GPL'ed code it is simply not permitted, except in the case of fork/exec. Of course we do not yet know exactly which Licence AMOSPro will be released under so this is a moot point at the moment. Please let it be BSD.

However AMCAF could be integrated if the licence was changed. I won't ask, I consider it an insult to ask an author to change their licence. Just my view.

Otherwise AMCAF compatible functions or optimised functions would have to be written from scratch.
[Edit 27/09/12] Got this totally wrong, AMCAF is not GPL, it is closed source, previously shareware now released freely to the Amiga community. My apologies to Chris Hodges and the community for this mistake.

Your queries come down to whether or not the parser/Tokeniser is optimised/designed to cater for these.

There is no reason why a more optimised function cannot be written and added under a different function name and the parser/Tokeniser updated with the new function name.
    Alternatively the parser/Tokeniser could be modified to recognise alternative implementations with an IDE setting of use "optimsed functions" or "use legacy compatibility".
    So you would use the RND command and together with the IDE setting the parser/Tokeniser would use the original legacy RND function or an optimised RND function.
    The parser/Tokeniser could also be modified to recognise an external function set (from extensions) and check if the extension was loaded, if not use an alternative (preferably optimised) internal function and provide a warning tag in an output log window.

Although AGA is the great potential benefit of a source release, I would be equally (maybe more) supportive of the development in terms of final-product output speed... more efficiently produced code.  BLITZ has been described by some people as jsut a clever set of ASM Macros.... and thus why it produces good, fast, programmes... why shouldnt AMOS3.0  be like this...

...Wouldn't you love to just re-compile your old AMOS code in a new version and suddenly find it so much faster?

I think you are suggesting precedence being given to produce more optimised and efficient functions and compiler rather than nice new features. I believe that is how bruceuncle wants to proceed in the early stages and I would agree. Get the core functionality fixed and fully optimised and then build on that.

I am suggesting features be suggested to aid in milestone release management. i.e. were is it going.

..., but with the commands and interface we all know and love? 

By this do you mean keep the original interface.
I would therefore suggest that the interface has a dual mode using separate libraries. A classic interface and an updated interface. I would however agree that the classic interface takes precedence during the initial development cycles through to version 3.0.

Wouldn't you love to not need to scour through optimisation 'tips' and just get on with writing your programs?...

We should consider integrating these tips to save devs time.

...For example, I am constantly frustrated by using GOSUBs where i could/should be using nice tidy procedures... sometimes only 1 or 2 lines long!

Could you provide some sample code for this (preferably commented) so it can be added as either a BUG or a feature update. This would give a reference to work from when the issue was being addressed.

p.s. my view is Amiga Classic, and ASM output should alway be the 'core' ...

Noted.

Anyway....

IF AGA = TRUE THEN GOSUB PAAAAARTY!

This is also a big want for me too.
This does lead to another point/suggestion that should be made. Developers do not have to become core developers to submit code etc. They can work on any feature, only that core developer code from a feature set is implemented first.
    So if I wanted to develop this separately from the main development I could but it would only be implemented after the current selected feature sets have been implemented, and only if there was time in the release schedule.
   Remember the development [EDIT] development management system hasn't been fully developed, peer reviewed and ratified by Lord Vetinari.

In development management, everything is a feature, a bug fix, an optimised function, a new function or interface element. In this case a feature is just a thing.


bruceuncle will no doubt be along to add his views.

I have just been informed that my dinner is in the dog. women.

[bruceuncle]

Feeling the heat from this bonfire already  .

Very nice to see so much interest being stirred up.

Thanks for the Design Process docs MadAngus.  I was always a lousy project manager.  Much preferred to get my hands dirty instead.  However, politically, I lean towards the 'benevolant dictator' model.  The problems being that "All power corrupts.  Absolute power corrupts absolutely." 

Rather than go through this point by point from the replies, I'll add a few bits to the existing, rather patchy, mission statement:

• Top priority is getting the original V2.0 fully documented as to what it does now and what we speculate it should be doing where things don't behave as expected.  So this will take (is taking) some time.
• No one has any right to prevent anyone using this opportunity to go-it-alone if that is their wish.  I just want to see an 'approved' AMOS Factory development lurking in the background with a reputation for stability, completeness (is that a word?) and integrity.
• In winnowing out what the goals and aspirations will be, there will need to be some hard decisions.  Not everyone will agree with them.  So we need to continue the 'fully documented' aspect of AMOS so that the community will understand those decisions.
• It's going to be hard to steer away from the 'camel' analogy (a camel is a horse developed by a committee  ).
• No compiler will ever suit all needs.  The fastest code will always be written in assembler.  I'll stick my neck out and state that it will be unlikely that much more siginificant improvements in compiled code performance is achievable.  I suggest that developers use AMOS and the Compiler until they bang their heads on performance problems and then integrate machine-code as required to achieve their goals.  That's what I did in a yet-another-music-editor that I worked on in AMOS The Creator years ago.  When I needed a fast re-sampler I coded it in assembler and integrated that into the AMOS code.  AMOS is well set up to allow integrated machine-code (machine-code folded Procedures, Pload, memory banks to store it in, Call, etc., and even allows calls to machine-code from the DBL (Interface) and Menu sub-languages.  To take it further than that is probably chasing a mirage.  My only personal wish-list entry in that vein would be the ability to add in-line assembly source.  But I don't see that as an important step in view of that existing support for machine-code.
• When it comes to what is used from the vast array of Extensions out there, I take the view that some are very useful, some are very task-specific, and some are not at all useful.  To take Hungry Horace's specific example of AMCAF's QRND.  Nothing should compromise existing AMOS code.  AMOS's RND may well be impoved (I don't know cos I haven't looked, yet) as long as it doesn't break that rule.  Anything else would be a new instruction.  I speculated elsewhere that this may mean a meatier AMPOSPro.lib, if possible, with the 'best of the rest' incorporated.  It may also mean an 'approved' Extension that re-writes the 'best of the rest' into one add-on package if the former is not possible.  The distinction is what we should regard as language-specific (and here, RND and QRND are good examples) and what is task-specific (e.g. TOME).
• Where existing stuff just doesn't work, we will need to decide whether it's worth fixing.  Again, a couple of examples may clarify what I mean.  E.g. #1.  Global should be able to take wildcards according to the docs.  But it doesn't.  Should it be fixed?  Is it worth the effort?  E.g. #2.  Def Fn and Fn only work in the scope in which they're declared.  That is, it will either be global or Procedure specific.  It would be far more useful if a Def Fn at global level is available within Procedures.  Should that be fixed?  More questions than answers at this stage.

Anyway, gotta go as I'm running late for an appointment.  Thanks to everyone for the feedback and enthusiasm.  I'll be back ... 

[Hungry Horace]

@ MadAngus

To clarify, with regards to optimaisations, i was largely referring to those documented by Spellcoder, which includes the procedure vs. gosub route.

http://www.amigacoding.com/index.php/AMOS:Optimizing
http://www.amigacoding.com/index.php/AMOS:Optimizing_Miscellaneous
http://www.amigacoding.com/index.php/AMOS:Optimizing_Coding_Style

I have tested it, and it is true, AMOS is slower with procedures than with gosubs! 

Anything to get the emphasis away from "you need to do this to make it work/better/quicker" and back towards the natural intuitive way AMOS can allow you to code, should be encouraged with any future developments (i beleive) as it  not only frustrates those of us who like to code in this lovely language, but the speed issue (or lack of optimisation) is usually the first "belittleing" of AMOS that happens from coders of other languages!

I'd also like to say that my comment about the classic interface shouldnt mean i wont welcome any change, but bear in mind, if you lose too much of it (for example going back to a raw test editor!) then you will lose some of what makes AMOS .... well... AMOS!

[SamuraiCrow]

@Hungry Horace
The QRnd function on the AMCAF extension is just like Rnd(65535) but without the modulo operator used to bring it into range.  I wouldn't be surprised if the QRnd function was just a rebadged AMOS Rnd function with that single change.

The subroutine procedure vs. Gosub argument has to do with the way that AmosPro passes parameters to the procedure.  It is purely stack-based.  In order to get it to be as fast as, say... SAS/C, it would need to be totally reengineered to use register-passing.  All extensions would need to be reengineered to take those changes into account as well.

@Mad Angus
Who ever said that AMCAF was GPL?  I thought it was closed-source or at least it was, last I knew.  I realize I've been off the scene for a while but I don't see any source code for the AMCAF extension on Aminet.  Has Chris Hodges rereleased it as GPL?

@Thread
Let's consider what's realistic compared to what isn't:  XAmos is a C++ based interpreter with plans to write a compiler that will generate C++ codes.  It would require GCC running on the Amiga to be able to compile, assuming it will still be C++ code.  If not, VBCC could be used if it was rewritten in C or something.

In the past I had high hopes that the Clang compiler for LLVM could be used on the Amiga but it requires 2 GiB to link in its current state, meaning that a Classic Amiga would never be able to recompile its own source code.  Also, Clang is a 22 MiB executable file on x86 and I doubt it would be much smaller on 68k.  This leaves us with an ugly implementation of GCC as being the only free C++ compiler for Amiga.

I know that Mequa had said in the past that since the XAmos project is BSD licensed, extension capabilities wouldn't be necessary in his interpreter.  I think he has similar plans for the compiler.  I'm all for Mequa doing what he wants with his own code but mixing it with a project written entirely in 68k Assembly such as AmosPro would break the bank in terms of both system requirements and development time unless Mequa or somebody figures out how to make a shared library or linker library out of his routines so that they can be linked externally.

I think getting AGA capabilities into AmosPro is a more realistic first step.  There have been numerous attempts at AGA extensions for AmosPro with varying degrees of success.  Let's just concentrate on that for now.  Do we want to totally redo the compiler though?  I'd recommend it if there's enough manpower to do it.

Let's talk.  Any further thoughts?

[MadAngus]

Quick post in response to AMCAF being GPL.

After checking I realise I got this totally wrong, AMCAF is not GPL, it is closed source, previously shareware now released freely to the Amiga community. My apologies to Chris Hodges and the community for this mistake.

The previous post comment about this has been struck out.

Going out to sign for a new car, I'll stick my neb in about the rest when I get back.

[Sidewinder]

I think getting AGA capabilities into AmosPro is a more realistic first step.  There have been numerous attempts at AGA extensions for AmosPro with varying degrees of success.  Let's just concentrate on that for now.  Do we want to totally redo the compiler though?  I'd recommend it if there's enough manpower to do it.

Let's talk.  Any further thoughts?

I agree with Sam about rewriting the compiler/interpreter.  If the source code is in a similar condition to the Creator sources already available then there is much cleanup to be done.  Making things register based would certainly speed it up and there is room for more efficient code generation.  A more system friendly design strategy would help modernize it too.  I think it may be time to start with a clean slate, and only use the source code as a complete reference for compatibility requirements.  (Although, after further consideration, using the current source code would be best to begin with, but before the 3.0 release the entire source code should be reviewed, cleaned up, documented, modularized, and updated.)

Implementing AGA would also be a worthy first step.  There are a hundred different features and changes I'd like to see, but updated code generation and AGA are the two big ones in my book.

And I would like to volunteer as a primary developer, if there are still openings.

[Hungry Horace]

@Hungry Horace
The QRnd function on the AMCAF extension is just like Rnd(65535) but without the modulo operator used to bring it into range.  I wouldn't be surprised if the QRnd function was just a rebadged AMOS Rnd function with that single change.

The subroutine procedure vs. Gosub argument has to do with the way that AmosPro passes parameters to the procedure.  It is purely stack-based.  In order to get it to be as fast as, say... SAS/C, it would need to be totally reengineered to use register-passing.  All extensions would need to be reengineered to take those changes into account as well.

I think the point I was making is being lost a bit, with focus on the examples I gave.... QRND and Procedure vs. GOSUB  were arbitrary examples of one replacement function, and one structural optimisation.

I could just have easily stated DRAW and TURBO DRAW, and using  REPEAT/UNTIL instead of FOR/NEXT.... even the terrible slow-down that occurs when using multidimensional arrays. The function example doesnt have to come from AMCAF at all!

My point is that the genuine improvements in what AMOS needs (i think) are not in it's commands or functions, it's possible to already achieve things that appear beautiful with AMOS.... It's the final code it produces as a result, and the results they achieve that AMOS is measured against with it's competitors.

I said it earlier, and I'll say it again - AMOS gets knocked (and sometimes deservedly so) because of the poor speed and performance of it's code... this is a shame, because it's actually an incredibly elegant language!

I'm not claiming that access to the source-code is a magic solution to this 'problem'.... but it has to be a lot of help, and I hope that whoever takes on this mammoth challenge (because lets not pretend it's any less than that!!) has these kind of considerations in mind

I think getting AGA capabilities into AmosPro is a more realistic first step.  There have been numerous attempts at AGA extensions for AmosPro with varying degrees of success.  Let's just concentrate on that for now.  Do we want to totally redo the compiler though?  I'd recommend it if there's enough manpower to do it.

Dont get me wrong, I think AGA functions are a very worthy 'early' aim.... and certainly one that would bring AMOS out-of-the-dark....

[MadAngus]

Welcome aboard Sidewinder. +1 Core Developer

Sidewinder is there a specific area of AMOS that you would prefer to be working on.

There is no limit on numbers, anybody can work on anything they want and submit it anytime. Obviously this would have to managed.
I'm not a developer in this project, not got the skills

To achieve everyone's wishlist, this project would have to be managed, with rules, code standards, implementation/work schedule, milestones etc. This may not be popular but it has been stated that the goal is a Horse not a Camel.

I'm volunteering as Project Manager, this would be an administrative role (not a decision making role), collating information, keeping any plans and design processes upto date, documentation updates, project website updates, asking questions that make you senior developers eyes role etc.

When I say collating information this also includes scouring every AMOS thread/post in existence including the mailing lists for anything that will help.

------------------------

Optimisations: How will we know what we need to work on and why.

I propose that a comparison list of AMOSpro and extension functions is created including other issues as highlighted by Hungry Horace. This list will highlight each AMOSpro function and it's equivalent in other extensions see sample table below.

AMOSPro		AMCAF
RND		QRND

From this table functions/process that are better optimsed are noted and documented, with further research indicating why the optimisation is better. For example:

Hungry Horace states:
AMOS  has a 'RND' command, but this is replaced by AMCAF's 'QRND' in practical usage.

This is followed up by SamuraiCrow's statement:
The QRnd function on the AMCAF extension is just like Rnd(65535) but without the modulo operator used to bring it into range.

This information changes our table to:

AMOSPro		AMCAF		Ext Better		Better Why
RND		QRND		Yes		The QRnd function is just like Rnd(65535) but without the modulo operator used to bring it into range.

Many areas of the AMOSPro and the extensions will require further research into the precise cause of weak implementations and any necessary steps that would be required to resolve the issue.

@Hungary Horace: This also applies to the final code performance issue, what, why and where are the weaknesses that result in the interpreter/compiler generated code not performing as well as the competition. A research task for someone to take on when the code is available. Does Devpac have a profiler, is there one that can be used for this task?

With the necessary work load for each issue known and collated, areas to focus work on can be manged and scheduled.

We do have the advantage that Lonewolf10 has already produced an extensive list of extension functions and has documented many of them. In addition the AmigaCoding team has already collated a lot of information.

This does not mean that work could not begin on specific features such as AGA or even an alternative interface, but when it is being put together it will have to be managed.

Q, Which code repo to use?
SVN, GIT, HG, CVS

Alternative interface:
There is only one way I can see this working. Firstly focus on keeping the classic interface as is until a much later stage. Then if desirable design an alternative optional interface, in such a way that the program can start up with the interface of choice.
    If features of the alternative optional interface is deemed suitable to be implemented into the classic interface and will not result in the loss "of what makes AMOS .... well... AMOS!" Then port them across.

[Sidewinder]

Thanks MadAngus.  I'm very interested in code generation and optimization, so I could focus on those areas.  But I'm a versatile programmer so I can do whatever needs to be done.

I think you'd make a good Project Manager.  We do need standards, rules, and plans.

Determining what to optimize should probably involve a complete code review once the source is released.  Various programmers/individuals could suggest improvements and those request could be compiled into a priority list.

Regarding repo, I'll vote for SVN or CVS.

[MadAngus]

Quick note:

Any standards, rules, and plans get peer reviewed by the community and ratified by the project lead after any necessary modifications are made.

[Edit] [Edit again]Tommorow night This weekend* I will be building a small summary of views expressed so far for further debate along side any new points of view.

So please have your half bricks ready. Anybody who manages to hit me wins a Gonk.


[From Edit] *I'm updating the AIAB download page at the moment, get that done and I'll move back onto this.