Official update to OS 3.1 from Hyperion

[wXR]

@olaf

"The value of the Amiga assets does not grow, because the owners do not invest enough time and energy to get the measure of, maintain or improve its value."

I think you may be spot-on there sir.

[Toni Wilen]

Originally Posted by Toni Wilen

When I can compile aros with "fixed" gcc (without too much pain!), I'll check if code looks better

AROS m68k GCC 6.3.0 has following very obvious "issues" after quick disassembly check (Didn't bother to check any non-obvious ones):

- LEA/PEA are always absolute, even if EA is inside +-32kb and it is in same module.
- Always JSR 12345678, never BSR (same as above)
- cmp.w #0,An; Bcc vs (if unused data register is available) move.l/w An,unused Dn; Bcc
- move.l 4.l,A6, never move.l 4.w,a6

Fixing these would save lots of bytes and also increase performance a bit.

[alpine9000]

Originally Posted by Toni Wilen

AROS m68k GCC 6.3.0 has following very obvious "issues" after quick disassembly check (Didn't bother to check any non-obvious ones):

- LEA/PEA are always absolute, even if EA is inside +-32kb and it is in same module.
- Always JSR 12345678, never BSR (same as above)
- cmp.w #0,An; Bcc vs (if unused data register is available) move.l/w An,unused Dn; Bcc
- move.l 4.l,A6, never move.l 4.w,a6

Fixing these would save lots of bytes and also increase performance a bit.

That's interesting stuff.

For the game I am working on, I am using bebbo's gcc, but with my hacks to enable me to use vasm/vlink.

vasm does some of what you describe above for me, and if I compare the code size of the main game code (no data) between no vasm optimisations and the (potentially unsafe, but seems to work fine) vasm optimisations I use, this is the size difference:

potentially unsafe optimisations: 48600 bytes
no optimisations: 51092 bytes

Speed wise, this number is the number of scan lines taken to render a game recording:

potentially unsafe optimisations: 653275
no optimisations: 657640

So not a bad size gain and a tiny speed increase.

For the record, these are the vasm optimisations I use:

-Wa,-opt-allbra -Wa,-opt-brajmp -Wa,-opt-lsl -Wa,-opt-movem -Wa,-opt-mul -Wa,-opt-div -Wa,-opt-pea

[wawa]

Originally Posted by Olaf Barthel

There is a worse outcome, which I expect might be more likely.

which unfortunatelly puts the open sourcing effort in an even more remote perspective.

[wawa]

Originally Posted by Toni Wilen

AROS m68k GCC 6.3.0 has following very obvious "issues" after quick disassembly check (Didn't bother to check any non-obvious ones):

- LEA/PEA are always absolute, even if EA is inside +-32kb and it is in same module.
- Always JSR 12345678, never BSR (same as above)
- cmp.w #0,An; Bcc vs (if unused data register is available) move.l/w An,unused Dn; Bcc
- move.l 4.l,A6, never move.l 4.w,a6

Fixing these would save lots of bytes and also increase performance a bit.

toni, maybe it could be better discussed and sorted out with kalamatee in the developer mailing list? we are driving this thread off topic big time.

[matthey]

Originally Posted by Toni Wilen

AROS m68k GCC 6.3.0 has following very obvious "issues" after quick disassembly check (Didn't bother to check any non-obvious ones):

Is this still compiled for the 68000? How about posting your findings to bebbo's unofficial GCC thread and continuing this discussion there?

http://eab.abime.net/showthread.php?t=85474

Originally Posted by Toni Wilen

- LEA/PEA are always absolute, even if EA is inside +-32kb and it is in same module.

I wonder if a 68020 compile would have this problem. The 68000 ISA only has (d16,PC) and (d8,PC,Xn) so there would need to be displacement size checks where the 68020 ISA would automatically convert to (bd,PC,Xn) as needed.

Originally Posted by Toni Wilen

- Always JSR 12345678, never BSR (same as above)

This is bad if "always" true and really hurts code density. It is possible that it sometimes happens with statically linking code and hunks are combined. This happens with vbcc generated code sometimes.

Originally Posted by Toni Wilen

- cmp.w #0,An; Bcc vs (if unused data register is available) move.l/w An,unused Dn; Bcc

The 68000 ISA does *not* allow TST An.

Originally Posted by Toni Wilen

- move.l 4.l,A6, never move.l 4.w,a6

GCC 2.95.3 and 3.4.0 did not optimize this as I recall either. This is sad as it is a simple and safe peephole optimization. This should not be common though.

Originally Posted by alpine9000

For the game I am working on, I am using bebbo's gcc, but with my hacks to enable me to use vasm/vlink.

...

For the record, these are the vasm optimisations I use:

-Wa,-opt-allbra -Wa,-opt-brajmp -Wa,-opt-lsl -Wa,-opt-movem -Wa,-opt-mul -Wa,-opt-div -Wa,-opt-pea

If you are using the default vasm mode (-phxass is/was the default with vbcc but work is progressing on changing to vasm mode) then most safe peephole optimizations are enabled by default. I would stick to the safe optimizations for compiler generated code. The -opt-lsl, -opt-movem, opt-mul, -opt-div, -opt-pea and -opt-st have different CCR results so are *not* safe.

[NorthWay]

Originally Posted by wXR

@NorthWay

Have you ever published the diff-patch to exec for that?

No, I never expected it to be of interest as it eats 64K chipram. I changed LOWEST_USEABLE_040 constant (to $F000 it seems - maybe there was a problem to go all the way up to $10000).

(And yes, Space Ace was the name of the other one. But I can't find that bug when looking for it now. How certain I was...)

[alpine9000]

Originally Posted by matthey

If you are using the default vasm mode (-phxass is/was the default with vbcc but work is progressing on changing to vasm mode) then most safe peephole optimizations are enabled by default. I would stick to the safe optimizations for compiler generated code. The -opt-lsl, -opt-movem, opt-mul, -opt-div, -opt-pea and -opt-st have different CCR results so are *not* safe.

Yeah, actually these unsafe options almost never trigger an optimisation with the gcc generated asm. Only the opt-pea actually made a difference to the above test and it was "safe" in that circumstance but insignificant, so you're right, the default optimisations would be best and would only change my above results by a few bytes.

[gulliver]

Originally Posted by NorthWay

No, I never expected it to be of interest as it eats 64K chipram. I changed LOWEST_USEABLE_040 constant (to $F000 it seems - maybe there was a problem to go all the way up to $10000).

(And yes, Space Ace was the name of the other one. But I can't find that bug when looking for it now. How certain I was...)

Could you post the instructions on how to patch exec this way? Or provide a patch file?

[matthey]

Originally Posted by NorthWay

No, I never expected it to be of interest as it eats 64K chipram. I changed LOWEST_USEABLE_040 constant (to $F000 it seems - maybe there was a problem to go all the way up to $10000).

(And yes, Space Ace was the name of the other one. But I can't find that bug when looking for it now. How certain I was...)

ThoR's Mu Libs package can use the MMU to protect the zero page (with optional read/write detection) while being compatible with programs which expect the VBR to not be moved and providing maximum performance for legitimate zero page accesses. Too bad some FPGA CPU designers don't like MMUs which support virtual addresses because they hyper-optimize for an FPGA, not to name any names.

[NorthWay]

Originally Posted by gulliver

Could you post the instructions on how to patch exec this way? Or provide a patch file?

You can't really binary patch it further than $7000 as it is optimized to be a word size value.
The pattern should be $41f8,$1000,$43fa. The $1000 is the start address, but changing it to $8000 and above is $ffffxxxx equivalent IIRC. Replace $1000 with $7000 and recalculate the ROM checksum.

[gulliver]

@NorthWay

I ask this because one of the issues with exec 45.20 on the MacroSystem DraCo is that it has no memory at all at zero address, unless the AmigaOS MMU setup is still active,and then it's only virtual.

DraCo memory starts at 0x4000 0000, 0x4200 0000, 0x4400 0000, 0x4600 0000,
with at least 4 MB in the first slot, and not more than 32 MB in each slot.

The AmigaOS MMU table is somewhere in the first 2 MB.

A full 128 MB DraCo looks like this with NetBSD:

memory segment 0 at 40000000 size 00200000
memory segment 1 at 40200000 size 07e00000

So patching exec 45.20 to acomodate that might have a chance to make it viable on this machine, because currently, it just doesnt work.

[Kalamatee]

Originally Posted by Olaf Barthel

My overall impression is that we are dealing with what I would call the "uncaring God scenario".

I agree with the sentiment and have for many years now. The people who truly made AmigaOS great where not the people who made AmigaOS. its all the bedroom/backroom coders who populated the fish/aminet collections with all the software that was great at the time.

If that isn't the truth, I'd like to see an untruth even half as convincing

Seriously, the Amiga operating system is a platform. Even if one were to succeed in making the source code available for scrutiny, modification and development, what makes the whole package work is the application software, the hardware, and what you can accomplish with it.

Very true - but at the same time people have high expectations of what the base operating system should provide these days so its about striking a balance.

The Workbench software does not ship with a lot of productivity tools, and nobody boots it just to admire how fine the icons look like, and how responsive the user interface is. The Amiga operating system is a tool, so let's not forget that the hand which wields it gives it purpose. That can be done right now, without waiting for a potential free Amiga operating system to materialize first.

That's true also, but there is a growing trend/sentiment in people to work together to achieve/improve things without the desire of ego, which personally I don't feel some of the "old school" developers like or can adapt to.

Compared to other "platforms", that have open source communities - the AmigaOS community is very uncooperative/hostile unless you just agree and nod to everything, and this is a comment that's often made sadly.

IMHO this is partly because the small community that remains have been manipulated by the few people who can milk them, into keeping things that way.

[wawa]

Originally Posted by Kalamatee

and nobody boots it just to admire how fine the icons look like

i have the feling, there is such a group..

[Locutus]

Originally Posted by wawa

i have the feling, there is such a group..

There is a group that boots up just for SysInfo, so hey....

[wXR]

@Kalamatee

All very well-observed points there sir. I might add that the bad seed of hostility was probably borne of Commodore's demise, and all of the terrible consequences that came of that. To be an Amiga user was somehow linked with strange psychological abuse early on.

[wXR]

@Kalamatee

All very well-observed points there sir. I might add that the bad seed of hostility was probably borne of Commodore's demise, and all of the terrible consequences that came of that. To be an Amiga user was somehow linked with strange psychological abuse early on.

[Olaf Barthel]

Originally Posted by wawa

which unfortunatelly puts the open sourcing effort in an even more remote perspective.

Please keep in mind that there is a good bit of speculation on my part here. It is one of the possible scenarios which I believe had not been covered yet (and which is not too outlandish either).

If and when somebody figures out who is actually responsible for making decisions on the fate of the Amiga operating system, and in addition being responsible for it, is also able to make changes stick, we'll know for sure what immediate obstacles exist. Until then there is just speculation.

[wawa]

olaf, if you dont know for sure, who of us is supposed to know?

[Olaf Barthel]

Originally Posted by Kalamatee

Compared to other "platforms", that have open source communities - the AmigaOS community is very uncooperative/hostile unless you just agree and nod to everything, and this is a comment that's often made sadly.

IMHO this is partly because the small community that remains have been manipulated by the few people who can milk them, into keeping things that way.

You make this sound like a bad thing

Seriously, this is in my opinion a side-effect of very few players remaining in this field who can to a certain degree control what products may be made and sold. How much control they actually have is limited by budget constraints, personnel involved, time available, actual sales and legal restrictions.

Few players being involved means that any decision made by them can instantly have far reaching effects on the market, the business and the hobbyists, both for better and for worse.

The limitations which the players have to work under always dictate how much risk they may be able to take, also for better and worse.

Finally, there is also competition between the players, among and against each other, which adds another level of risk and uncertainty on top.

If this were any other kind of business, would you reasonably want to be involved in it?

You mentioned milking. I believe that the term may not apply here. The constraints are not created by the players, they just have very little room to conduct their businesses. This in turn leads to the sometimes baffling decisions as to what kind of product can be released, and at which price.