[gmpi] Re: Topic 3: Cross platform
- From: "Laurent de Soras [Ohm Force]" <laurent@xxxxxxxxxxxx>
- Date: Thu, 06 Mar 2003 13:42:05 +0100
> 1. What processors (or processor architectures) are to be supported?
>
> Whatever processors are supported by O/S's we choose to support in (2).
I also agree with the requirement for 64-bit
architectures. They even should be favoured over the
current 32-bit ones as they will become the standard
pretty soon.
> 2. What operating systems are to be supported?
>
> In general, all popular contemporary O/S, leaning towards more recent
> versions: Windows 2000, Windows XP, Mac OS-X, Linux, other Unix variants,
> Pocket PC, Palm O/S
Let's say that Win/MacOS/Linux are "primary targets". I mean
that there's would be no real problem for GMPI to adapt to
other OS as long as these primary targets are all supported
correctly.
I also think about possible non-xplatform parts. It could be
necessary to specify them explicitly within GMPI at least for
the primary targets.
> 3. What kinds of addressing models are to be supported?
>
> Determined by the processor architecture, right?
Yes, but it needs to be defined somewhere :) The problem is :
Does host and plug-in share the same memory space, with a
common addressing method ? Is it reasonable to require
that host and plug can pass arguments by addresses ? IMHO
yes, at least at the plug-host interface level. If "real"
plug is based somewhere else, the plug-in interface has
in charge to actually transfer data between host space
and plug-in space.
> 4. What programming languages are to be supported?
>
> Standard C (which supports C++ by extension), with very clearly specified
> calling conventions (cdecl vs. stdcall).
Yes, C [cdecl] calling convention is a good and classic
requirement, I think there is no need to go further. I assume
here that there is an "official" C calling convention for
each supported platform, so there isn't any ambiguity with
its implementation.
> 5. Level of heterogenity on microcontroller+DSP based systems.
>
> I don't know what this means.<g> I was on the agenda list, but I can't
> recally why. Possibly not applicable?
Urs Heckmann <urs@xxxxxxxx>, Wed, 12 Feb 2003 18:12:36 +0100:
> I'd like to explicitly add to this question something like "level of
> heterogenity" where systems may not only be based on a single type of
> processor (i.e. Microcontroller = communication, DSP = process) or PCI
> cards...
I think it's not applicable, as we concluded that the plug-in
part should wrap communication for "alien" architectures.
Someone wrote:
> I think our best bet is to identify the OS bits that we need to control
> carefully, such as memory allocation, thread synchronization, and (maybe)
> disk IO.
Another quote:
> the API should allow hosts to present a "callback suite" (to
> paraphrase mike berry) that encapsulate any functionality that might
> have to originate in the OS.
I think it's not in the GMPI scope. Indeed these
functionalities are useful and most of the plug-ins have to
deal with such issues. But they should be part of another,
separate API, ie focused on "cross-platform ressource
management in a real-time environment".
-- Laurent
==================================+========================
Laurent de Soras | Ohm Force
DSP developer & Software designer | Digital Audio Software
mailto:laurent@xxxxxxxxxxxx | http://www.ohmforce.com
==================================+========================
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
