From:    Bill McEwen bill@amiga.com
Subject: VP "Omissions" and problems re SDK...
Date:    Fri, 7 Jul 2000 10:08:01 -0700

Answer to this posting from John Wiederhirn on comp.sys.amiga.misc

Regarding message from J.F. Wiederhirn,

There are some valid points, but you overemphasise the points significantly.
The extent to which you dismiss the platform is at odds with the reality of
the graphics and Java performance [for example].

> 1.  Efficient register usage...or the lack thereof.
>
> VP code allows (hell, suggests) you to registers whenever possible.
> They scope registers at subroutine limits (among others, the details
> aren't really relevent to the problem).
>
> The problem is that you cannot direct register usage, or even
> prioritize it.  You can scope it slightly, by indicating when a
> register is last-used.  Every register usage is in the end evaluated
> by the translator and handled based on it's algorithms. Since (and
> I'll avoid the extensive mathematical proofs involved) their optimizer
> cannot understand more than basic algorithms, that means it is very
> difficult to do tight register-based optimization on code.

You cannot direct register usage, just as you can't in C. So really you are
saying that you cannot write as efficient code in VP as you can by
hand-crafting native assembler. This is undeniably true and nobody pretended
otherwise. VP does give you, however, a means of writing low-level code,
sacrificing the minimum of efficiency possible with a portable solution. For
ultimate performance, certain operations would need to be written in native
but when you don't do this, you still get near-optimal performance in a
portable manner.

> 2.  MMX, SSE, maybe someday?
>
> The reason for the vague answers regarding how MMX and SSE were to be
> supported is now very clear to me.  They aren't supported from a
> programmer standpoint as far as I can discern.  Even the documentation
> for the PII interfaces leaves it unclear whether platform-specific
> code (more on that in a bit) can safely use those instructions, since
> there's no documentation as to whether those registers are state-saved
> in the current SDK.

As it happens, they are saved.

The CPU documentation details which native registers are used by the VP
environment. Development of PII tools such as the first level interrupt
handler is directly based on that information. For example,
sys/cii/arm6/cpu.html gives the information about native register usage for
anyone wishing to write an ARM PII.

> The VP in the SDK does not appear to support any mechanism for issuing
> MMX or SSE instructions.

To get ultimate performance you would need to abstract at a library level
and develop native MMX-based implementations. So MMX type instructions can
be used now. They have not been abstracted into VP as there is no
sufficiently common model across all processors with MMX-type operations to
get any degree of efficiency. However, as noted in this paragraph already,
an application that can make good use of these instructions on a particular
processor can contain some native tools containing the MMX type instructions
for that particular processor. These tools can be macro-ised and embedded to
get code that looks and behaves like the MMX instructions were fully
supported.

Would you suggest an abstraction that could be used? You obviously have some
good ideas in mind for you to have made such comments.

> 3.  Cache?  Hello?
>
> This omission appears to be the second-most glaring to me, from a
> low-level perspective.  VP code has neither any concept of cache, nor
> any way to actually control it.  While that makes some sense from a
> software interpreter/compiler standpoint, it totally ignores that
> under the VP there is a real CPU with real cache.  The idea that
> meaningful driver code can be written is VP code is laughable given
> that the VP has no way to actually handle cacheable vs non-cacheable
> contents.

Cache? Hi!

This is not a VP issue at all. Do any processors have native instruction
modifiers that allow cache usage to be modified on a per instruction basis?
I do not know of any. I would have thought that most of this work will be by
programming a CPU register(s) to control the cache usage (i.e. coarse: turn
off at start - turn on at end for all memory operations on a memory bank.
fine: declare a pointer type to be uncached so that any use of that pointer
is not cached.). Note that in your question 4 there is a reference to
declaring a memory area as cached or not cached, so that is the level of
cache management expected. So, that is clearly not a VP issue. In fact,
intent is uniquely placed to take advantage of an architecture where cache
lines are controlled by individual flags within the pointer. The trouble is,
again, there is no good abstraction for this concept. It is up to individual
platforms and drivers to have these concepts defined and used if required.
And this is all perfectly possible on intent. An example might be that two
memory objects are declared, one returns cached memory, one not cached.
These can even allocate from the same underlying pool, although you are
likely to find that the cache is turned off and on at larger boundaries than
the byte.

The kernel and tool loaders are cache aware in that they call
sys/cii/flushicache during tool loading and code relocation to allow a
platform to clean/flush caches if required. Although this is a CII tool, it
is actually implemented in the PII since cache details may differ on
platforms with apparently similar cores. The tool is directly accessible to
device drivers if developers wish to use it. Where DMA and cache interaction
is an issue, the PII implementer would write tools for the device driver
writer to use to e.g. clean/writeback a DCache.

The whole point of the PII is that there is a fixed set of tools required by
the OS on all platforms plus a "platform specific" optional set that need to
be written to address specific issues on the target platform. This maintains
the portability and encapsulates the "dirty stuff" in one layer. PIIs have
successfully been implemented on many platforms with caches and "take
advantage" of the cache just like any software.


> 4.  Memory-space attributes.
>
> I don't even know where to start with this.  The PII mechanisms
> offered, as far as I could discern (and the documentation on this is
> far from centralized) appeared to support the following ops:  You can
> map physical memory to Amiga memory, and unmap it.  You can obtain the
> physical address of mapped memory.  You can do a couple other usual
> mapping tricks with that memory.
>
> You CANNOT set any attributes for the memory range in question, such
> as cached/non-cached, write-combined/non-write-combined, etc.  Who the
> hell's brain-fart was responsible for that?  Jeez, Tao's been tooling
> on this thing for years and years, and they never once thought being
> able to set stuff as non-cached was valuable?

The cacheing issue has already been covered. Any other attributes fall into
the same category. Have you come across write-combined/non-write-combined?
Even if these exist, it wouldn't really change anything. If a need is
identified, functions can easily be added to the PII. It has been
constructed to be extensible.

The primary focus for intent has been on embedded systems where the MMU is
used to set up a fairly simple memory space with mostly 1:1 translation from
physical to virtual space. These mappings are set up at boot time. The
mapping tools you refer to were developed several years ago for the DOS
platform and are not used on any other platform.

> 5.  Cross-platform.  Well, kinda.
>
> The docs themselves suggest that tools (think of em as DLLs, they work
> almost exactly the same as Windows DLLs) can hold multiple versions of
> the same code for different environments.  In fact, they specifically
> mention that optimized versions of code for a given environment can be
> included in a tool, as well as a generalized VP version.
>
> So much for platform neutrality and cross-platform compatibility.
> Their solution is no different than JNI, and suffers precisely the
> same issues.

This isn't true. JNI is not portably defined across platforms.
I don't see really what the complaint is here.

> 6.  Interrupts
>
> I saved this for last because, well, "the horror, the horror...".  As
> I've already mentioned under VP your cache control is non-existent.
> To the issue of interrupt handling, well, I can only pass along the
> trauma and suggest anyone really interested buy the SDK.  You'll be
> impressed to see the mechanism documented on paper, if ya don't tear
> out your own eyeballs.

I expect here you are commenting on the efficiency of the interrupt handing
model. Not altogether a surprise, if someone's obsessed by these issues.

There is nothing wrong with the interrupt model for 'normal' usage
platforms. Those who are obsessed are at liberty to fit in their own
architecture here. Platforms with little hardware support for devices may
also need to do the same thing to be able to service interrupts at a very
low patency. The intent model does not precluse this at all.

> On a personal note, I just got stuck in a wheelchair after a spinal
> injury.  I _really_ wanted this to turn out as a review of cool
> technology because my mood was already dour.  I'm left after viewing
> the technology wondering what the hell Tao's been doing for the last
> few years, and why Amiga thought this technology was
> desktop-appropriate.  The VP, while totally appropriate for embedded
> and handheld concerns, isn't remotely appropriate for high-bandwidth
> desktop concerns.

Some things are undeniably true, nonetheless. The 2D graphics functionality
and performance is unparalleled. This is all done in VP. It shows that using
this technology it is possible to develop highly performing portable
software (near optimal, not completely optimal on all architectures). The
JVM and libraries are still be best available. It is true that the
superiority of the technology is greatest in embedded space but to suggest
that it is worthless is not realistic.

Finally, it is worth pointing out that it is impossible to refute bland
allegations that do not give any substance.

• DECH (Version 1.37) - dech.lha
• DRemind (Version 1.54b) - dremind.lha
• MultiRen (Version 1.4) - multiren.lha
• QuickNote (Version 1.3) - quicknote.lha
• TheMPegEncGUI (Version 2.03) - thempegencgui.lha

StarBase_SCR.lha     biz/dbase  110K+Star Trek Episodes Database (v2.1)
TAdesivi.lha         biz/demo    42K+V1.0.3 Ticket editor for TurboGest (ITAL
TBolDEMO.lha         biz/demo    71K+V1.3.1 Material receipt program,(BOLLE M
TProspEd.lha         biz/demo    59K+V1.0.5 Form Editor For TurboFat (ITALIAN
AmIRC35-ITA.lha      comm/irc    15K+Italian catalog for AmIRC v3.5
dc240wizard14.lha    comm/misc  116K+Tool for Kodak DC240 digital camera
MiamiDxWebCP.lha     comm/net    18K+MiamiDxWebCP 2.3 - a Web Control Panel f
SimpleFTP.lha        comm/tcp   258K+SimpleFTP v2.64 - Powerful and easy to u
BlitzLstJun00.lha    dev/basic  138K+Blitz mailing list archives for June 200
BlitzLstMay00.lha    dev/basic  106K+Blitz mailing list archives for May 2000
advlite20b7.lha      dev/misc   270K+Powerfull & neat AutodocViewer v2.0 BETA
Aakt0700HTML.lha     docs/mags  277K+AMIGA aktuell - German infotainment maga
PD_Cheater_V25.lha   game/hint  447K+PD_Cheater, Cheats for PD Games (german)
pacman.lha           game/misc   98K+Pacman version 0.9B. 
Shuf2_upd.lha        game/patch 146K+Shuffle 2 - Mysted -> update to version 
Orbit_68k.lha        game/shoot 128K+Space Combat Simulator [040/060]
Orbit_ppc.lha        game/shoot 132K+Space Combat Simulator [WarpOS]
Orbit_src.lha        game/shoot 127K+Space Combat Simulator [Source]
GuessStress.lha      game/think 199K+GuessStress V1.5   
Shuffle3.lha         game/think 6.3M+Third part of a simple logical game, gre
CyberPiPView.lha     gfx/board   11K+Videolayer picture viewer (2.5)
amimdc800.lha        gfx/misc   131K+Mustek MDC800 Digital Camera Control
ChipEm.lha           misc/emu    71K+Chip 8 v0.3  Emulator by Balrog Soft
LottoV2.01.lha       misc/misc  434K+Play Lotto! (V2.01, req. 2.0) -Update-
LottoV2.lha          misc/misc  884K+Play Lotto! (V2.0, req. MUI)
NieMehrNachHs.lha    mods/smpl  4.0M+Nie mehr nach Haus! (8svx music sample) 
toccatamixer.lha     mus/misc    24K+Toccata sound card control program
AmigaAMPstart.lha    mus/play   164K+Welcome mpeg for AmigaAMP
UpRate.lha           mus/play     6K+Ensures top Paula samplerates always ava
PSI-Division.lha     pix/anim    36K+Splitting Greek
Trinity.mpg          pix/mpg     64K+This is first VHS demo created by Halluc
GED_Hexedit.lha      text/edit  235K+Hexedit Environment for GOLDED V1.40
wbstartup++.lha      util/boot   14K+Startup program launcher
WarpPNGdt.lha        util/dtype  48K+PNG image datatype (WarpOS/PPC) V44.5
asyncioppc.lha       util/libs   23K+Asyncio.library with WarpOS functions (V
lucyplay.lha         util/libs    9K+AHI Audio Player + Joystick Functions
calculator.lha       util/misc   25K+Fully functional scientific calculator
InstallerFXSou.lha   util/misc   34K+V1.10,InstallerFX Sourcecode(StormC).
ReportPlus.lha       util/misc   54K+3.2: Multi-function utility
xpkGZIP-WOS.lha      util/pack   22K+XpkGZIP module for WarpOS (V2.1)
LSClock.lha          util/time   22K+SHAREWARE clock utility
rndwbpix.lha         util/wb     11K+Random wbpattern picture selector (39.7)
yerfawt.lha          util/wb      2K+Yer Fawt! fault strings for "your Fault"

From    Pulse Publishing thepulse@pulsepublishing.co.uk
To      Amiga News team@amiga-news.de
Date    Thu, 06 Jul 2000 01:32:02 +0000
Subject Pulse Super CD

Hello,

Due to the massive response for The Pulse Magazine from retailers/distributers
and the Amiga public, we have managed to take an idea we had for later down
the line and put it into action for the very first issue!

And so, *The Pulse Super CD* has now become a reality.

When you subscribe to The Pulse Magazine for 6 or 12 months, you will gain
automatic inclusion to receive all issues of the Super CD released during
your subscription period.

The Pulse Super CD is a brand new peice of software put together by the
writers of The Pulse filled with tons of glorious goodies to entertain and
benefit all types of users.

Unlike other cover CD's which seem to be full of the same old stuff, each
SUPER CD contains 640mb of brand new, completely different goodies to the
last including:-

- All the hottest game demos, previews and screenshots
- All the latest serious software demos
- Hints, tips, cheats & solutions
- Quality workbench tools and accessories
- Workbench backgrounds, themes and screensavers
- Reams and reams of glowicons for OS 3.5
- Art Gallery
- Brand new custom made Directory Opus themes
- Full commercial games
- Full commercial serious software

The Pulse Super CD is designed to be released when we feel we can fill a
complete CD with only the best, top quality products, and ensure that each
and every issue has entirely different contents to the last.

Below are the highlights of the first release:-

- Full commercial games including:
    Abduction
    Charlie J Cool AGA & ECS Versions

- Tons of great game demos including:
    Wolfenstein 3D
    Heretic II
     Joyride
    U.V.W.
    Hell Squad
    HexenWorld

- Tons of great game updates including:
    Quake
    Frontier Elite II
    Virtual GP
    Foundation DC
    SWOS

- Serious Software Updates:
   Wordworth Fonts
    Pagestream Fonts

- Demo Scene featuring the best Amiga demos from around the world.

Don't forget, all this is only available to subscribers of The Pulse Magaine,
so get your subscriptions in today!

Release date for next issue is mid July....

Kind regards
--
The Pulse
No Way Out.....

Email: thepulse@pulsepublishing.co.uk
http://www.pulsepublishing.co.uk
------------------------------------
If you ever subscribe to an Amiga mag again this should be it!

From: John Zacharias jzachar@calweb.com

Subject: AmiWest 2000 Press Release 7
Date: Wed, 5 Jul 2000 06:55:36 -0700 (PDT)

FOR IMMEDIATE RELEASE

Eyetech Group Ltd will be exhibiting at AmiWest 2000!

On June 6, Amiga Inc. and Eyetech Group Ltd entered into a strategic
relationship for Eyetech to manufacture the first release of the Next
Generation Amiga Development Machine.  Eyetech will be coming to
Sacramento, California for AmiWest 2000 and will be showing off the Next
Generation Amiga Development Machine coupled with a Classic A1200 at the
show.

Eyetech is the leading UK developers and Worldwide mail order retailers of
Amiga technology products for the home and for industry.  They are the
manufacturers and distributors of the EZDev-Plus and EZDev-Tower Dev Boxes
in the UK and Ireland under a partnership agreement with Amiga Inc.  and
parent company of the Eye-Play (www.eye-play.com) games publishing and
distribution for the Classic and Amiga OE platforms

Products at the show will include:  EZRack 2U x 380mm 19" rack system
containing a full EZDev and Classic A1200 platform networked in the same
case; EZBoot silicon floppy disk allowing direct booting from CDROM on all
WB3+ Amigas; the AMON low distortion automatic monitor switcher for the
Cybervision64-3D and scandoubled AGA outputs; the EZLink AREXX-controlled
infrared controller 'learning' receiver/transmitter for all WB2+ Amigas;
the EZ-Net 5-click Linux-Amiga, Win-Amiga & Amiga-Amiga networking software
and installer; the EZ-VGA range of scan doublers and flickerfixers and much
more.

A rolling presentation under SCALA MM400 will show some of the products
that we physically couldn't bring with us, but regularly send to the US by
mail order.  These include:  the full range of EZDev configuration options,
the EZTower-Z4 A1200 tower system with Z4 expansion board (3 x Z2, 2 x
hi-speed Z2, 2 x 19MB/s Z4, 4 x clock port slots) and many more products.

Special dealer and User Group pricing will be available at the show.
Eyetech can be reached on the web at http://welcome.to/amiga.world

Remember, AmiWest 2000 is being held on Friday through Sunday, July 29-30,
2000 at the Holiday Inn, Sacramento NorthEast, in Sacramento, CA.  Classes
and seminars will be held throughout the day on both Saturday and Sunday
with the exhibit hall being open on Saturday, July 29th from 10 A.M.  - 5
P.M and Sunday, July 30th 10 A.M.  - 4 P.M.

Specially priced tickets for AmiWest 2000 are available in advance by mail.
Prices are:  two day admission tickets, $12 and one day admission ticket,
$8.  If you elect to purchase tickets at the door, the prices are:  two day
ticket at the door, $15 and One day ticket at the door, $10.  If you are
ordering a one day ticket by mail, please specify which day (Saturday or
Sunday) you are attending.

There will be a buffet banquet on Saturday evening, July 29th, with Bill
McEwen, President of Amiga Inc., as the guest speaker discussing the
progress made to date on the new Amigas.  Price is $35 per plate.  Banquet
tickets must be purchased in advance.  They will NOT be sold on Friday nor
Saturday due to the hotel needing attendance figures for planning the
banquet.

You can mail your requests for advanced admission and banquet tickets to:

      AmiWest 2000
      c/o John Zacharias
      10004 Vanguard Drive
      Sacramento, CA 95827

Make checks payable to "AmiWest".

A form for ordering tickets can be found on the AmiWest web page at

    http://www.sacc.org/amiwest/

where you can learn more about AmiWest 2000.

Petro Tyschtschenko, Managing Director, Amiga Deutschland Inc., will be
joining Mr McEwen in attendance at AmiWest 2000.

Special hotel room rates are available at the Holiday Inn for those
attending AmiWest 2000.  Room rates are $ 79 (Single) and $ 89 (double) if
reservations are made by July 7.  You must mention that you are attending
AmiWest to get the special rate.  You can phone the Holiday Inn at
1-916-338-5800 or 1-800-388-9284 (Tool Free - Hotel directly) to make hotel
reservations.

You will also be able to purchase the recently announced Software
Development Kit (SDK) for the new Amigas at AmiWest 2000.  The SDK is being
sold by several of the exhibitors at the show.

This weekend event will again showcase the progress that IS the Amiga
Community.

Hope to see you at AmiWest 2000 on July 29-30, 2000.

John Zacharias, chairperson
AmiWest 2000
jzachar@calweb.com
http://www.sacc.org/amiwest/