Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: AmigaOS and the Console Development - Part 1  (Read 7906 times)

0 Members and 1 Guest are viewing this topic.

Offline kolla

Re: AmigaOS and the Console Development - Part 1
« Reply #15 on: October 01, 2015, 09:17:25 PM »
Quote from: Thomas Richter;796700
What's the problem with ViNCEd?


Can I put it in kickstart?

Really, the problem with ViNCEd is that it is "too much". I am sure it has brilliant terminal emulation, but what is the point when there is no good ssh implementation?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: AmigaOS and the Console Development - Part 1
« Reply #16 on: October 01, 2015, 09:25:43 PM »
Apropos - Thank you Olsen for Term! I've been using it a lot lately, on MIST and Minimig, zmodem ftw :)
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline kolla

Re: AmigaOS and the Console Development - Part 1
« Reply #17 on: October 01, 2015, 09:28:19 PM »
Quote from: Thomas Richter;796700
What's the problem with ViNCEd?


Quote from: Thomas Richter;796706
Would "VeryNewCon"  be better? That's the initial name it was.


Just VCON? ViNCEd, it is neither vi nor ced, who knows what the "acronym" is supposed to mean? And the casing? Crazy.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline matthey

Re: AmigaOS and the Console Development - Part 1
« Reply #18 on: October 01, 2015, 09:39:10 PM »
Quote from: olsen;796689
Now, what exactly will SetWriteMask() do in this situation? It has the effect of making display updates more costly if an interleaved bitmap is used (which is the standard case). Instead of moving one consecutive chunk of bitmap data, the blitter operations have to be broken up into individual planes again. Available bandwidth is used less effectively. This can be noticeably slower.

Good explanation. So the SetWriteMask() is only an optimization for non-interleaved planar bitmaps? It now sounds like SetWriteMask() should be removed in all cases this "optimization" is used for AmigaOS 3+.

Quote from: Thomas Richter;796702
Please define "a lot". Or rather, take your time and benchmark console with the macro and without it, measure the difference and tell me. I haven't done that, admittedly, but just from your gut, what would you expect? 10% speed improvement? Not seriously. My gut feeling is: Below the statistical error. Way below. Don't waste your time in details.

I was talking about the macros vs the functions not the overall code speed which would be difficult to measure (it waits most of the time but should be fast when it doesn't wait). If you look at the macro vs function code on say the 68060, the overhead of a function through the LVO is at least 14 cycles (ignoring cache misses where inlined code like the macro has an advantage) for the JSR+JMP+RTS. For short functions like SetWriteMask() where the code is only a couple of cycles, this is significant. There is more overhead in setting up for a function call than using the macro also. The newer PPC processors are likely to have a link stack which might cut the function overhead in half but the macro is still significantly faster.

Quote from: Thomas Richter;796702
Compatibility? Readability? Maintainability? Actually, that's quite worth something. What I do not like about macros is that they require knowledge of the implementation details to work. In other words, they expose the internal structure you are manipulating to the compiler, making it impossible to change that without recompiling the code. Again, admittedly, it's already too late for graphics to fix that, graphics is all over with code that exposes internal interfaces where it should not, but please! can we avoid this problem in future code somehow? There are interface functions, and here we have a perfectly fine "setter" function for an internal property. It's good practice to use that.

Compatibility is a false claim if the code works fine with the macros (the original did). Readability is arguable. I agree that the library functions have maintenance advantages which is valuable. IMO, it comes down to maintenance vs speed. Maintenance may be the better choice on powerful processors but then some of the speed and responsiveness advantage the AmigaOS gives is lost so now a faster CPU is needed to make up for it. Maybe that would be ok if people weren't comparing a PPC Amiga with 20 year old embedded PPC CPU design to a modern PC with modern x86_64 CPU costing a fraction of the price.

Quote from: Thomas Richter;796706
Would "VeryNewCon"  be better? That's the initial name it was.

Why not ECON for Enhanced CON or Editor CON?
« Last Edit: October 02, 2015, 01:54:41 AM by matthey »
 

Offline candyman

Re: AmigaOS and the Console Development - Part 1
« Reply #19 on: October 01, 2015, 09:39:39 PM »
Too many technicalities... After two posts I have ceased to understand what you were talking about... :(

Anyway, may I suggest Miami ViNCEd? :)
 

Offline Hans_

Re: AmigaOS and the Console Development - Part 1
« Reply #20 on: October 01, 2015, 10:23:52 PM »
@matthey
Quote
Good explanation. So the SetWriteMask() is only an optimization for non-interleaved planar bitmaps? It now sounds like SetWriteMask() should be removed in all cases for AmigaOS 3+.

Uh, no. We want to move away from people peeking and poking about in internal OS structures.

Hans
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
 

Offline kolla

Re: AmigaOS and the Console Development - Part 1
« Reply #21 on: October 02, 2015, 12:26:50 AM »
Why must it have a new name anyways, just want something that replaces CON: and RAW: and that is more capable - call it console.handler with an appropriate version string.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline Duce

  • Off to greener pastures
  • Hero Member
  • *****
  • Join Date: Jul 2009
  • Posts: 1699
  • Total likes: 0
    • http://amigabbs.blogspot.com/
Re: AmigaOS and the Console Development - Part 1
« Reply #22 on: October 02, 2015, 07:48:33 AM »
Good read, thanks for posting the link.
 

Offline olsen

Re: AmigaOS and the Console Development - Part 1
« Reply #23 on: October 02, 2015, 09:36:41 AM »
Quote from: matthey;796714
Good explanation. So the SetWriteMask() is only an optimization for non-interleaved planar bitmaps? It now sounds like SetWriteMask() should be removed in all cases this "optimization" is used for AmigaOS 3+.


It's not that terrible, really. The blitter works exactly like it always did regardless of whether you restart it several times over for each individual plane, or let it rip for a single consecutive chunk of memory which comprises all planes. Noticeable gains are only possible on an AGA machine (higher bandwidth). On an ECS machine the effects will be less pronounced. In Super72 mode at four colours, ECS already has so much trouble at hand that it cannot always detect if the blitter is still running :-(

Where the write mask makes a big difference, however, is with RTG screens. Instead of jush pushing chunky pixels around, CyberGraphX/Picasso96/etc. now have to treat the screen as if it were a real planar bitmap, so that only the relevant data is affected when text is rendered or scrolled. This requires significant extra effort.

Ironically, the "optimization" of restricting rendering operations to a single plane now cause exactly the opposite of the intended goal.
 

guest11527

  • Guest
Re: AmigaOS and the Console Development - Part 1
« Reply #24 on: October 02, 2015, 12:07:15 PM »
Quote from: matthey;796714
If you look at the macro vs function code on say the 68060, the overhead of a function through the LVO is at least 14 cycles (ignoring cache misses where inlined code like the macro has an advantage) for the JSR+JMP+RTS. For short functions like SetWriteMask() where the code is only a couple of cycles, this is significant. There is more overhead in setting up for a function call than using the macro also. The newer PPC processors are likely to have a link stack which might cut the function overhead in half but the macro is still significantly faster.

Excuse me, no, it's not. You seem to assume a program that does nothing except calling SetWriteMask() in a tight loop without doing anything else, so the program speed is dominated by function call vs. macro.

However, that's certainly not the case here. If the program would make such tight function calls, the argument would be all different and I would agree that this is possibly something to consider in worst case.  However, we're talking about probably 20 cycles vs. probably 5 cycles somewhere in the middle of a large program where the 20/5 difference is only relevant in a small percentage of the overall code coverage.

So, in other words, the whole argument is mood. Don't worry about problems you don't have in first place. The dominant problem here is coding style, and that outweights the hand full of cycles nobody is able to measure or notice.
 

Offline QuikSanz

Re: AmigaOS and the Console Development - Part 1
« Reply #25 on: October 03, 2015, 02:51:08 AM »
Looks like your saying macros are a disaster in the waiting, Virus entry point!
 

Offline matthey

Re: AmigaOS and the Console Development - Part 1
« Reply #26 on: October 03, 2015, 05:28:27 AM »
Quote from: kolla;796719
Why must it have a new name anyways, just want something that replaces CON: and RAW: and that is more capable - call it console.handler with an appropriate version string.


If the new handlers can be enhanced while maintaining full backward compatibility, then keeping the same name and bumping the version is appropriate. Otherwise, a new name is required so that programs needing compatibility can use the old handler.

Quote from: QuikSanz;796756
Looks like your saying macros are a disaster in the waiting, Virus entry point!


Actually, the macros would reduce the chances of a virus as there are less functions to hook into, not that this is a concern in this case. The concern about macros is that the program accesses the elements of structures instead of calling a function to do it. The OS developers may decide to change the structures and the functions with it. This is more object oriented and easier to maintain but also significantly slower. Most Amiga programs already access some OS structures directly, with or without macros, so changing the structures will break compatibility. The macros are no more a disaster than the majority of AmigaOS programs which use macros and access the structures directly. It may be unfortunate that so many OS structures were documented and modified directly but it was fast and easy. To go away from this would be to break direct compatibility and instead provide compatibility through a sandbox. This may be necessary if moving to a completely alien CPU architecture after PPC finishes dying off.
 

Offline QuikSanz

Re: AmigaOS and the Console Development - Part 1
« Reply #27 on: October 03, 2015, 06:09:03 AM »
No way to separate Internal and external macros will eventually kill arex?
 

guest11527

  • Guest
Re: AmigaOS and the Console Development - Part 1
« Reply #28 on: October 03, 2015, 09:25:52 AM »
Quote from: QuikSanz;796761
No way to separate Internal and external macros will eventually kill arex?

ARexx has nothing to do with the problem, completely unrelated.
 

Offline kolla

Re: AmigaOS and the Console Development - Part 1
« Reply #29 on: October 03, 2015, 11:47:24 AM »
I suppose the idea is "convinced".
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS