> -----Original Message-----
> From: swiftx-bounce_at_forth.com [mailto:swiftx-bounce_at_forth.com]On Behalf
> Of Bulgrien, Dennis
> Sent: Tuesday, July 12, 2005 2:49 PM
> To: 'swiftx_at_forth.com'
> Subject: [swiftx] On the Abuse of Facility Variable Implementation
> Specific Details
>
>
> There is a concept that specific details about a given
> implementation should
> not be used opportunistically in higher layers for portability.
>
> One of these implementation details is the initial value of facility
> variables (used by GET and RELEASE ). The fact that they are zero when
> available/released is needed when declaring the variable. This
> implementation specific detail could be hidden with a word such
> as FACILITY:
> which would do VARIABLE and initialize the appropriate state. On
> the other
> hand, because this detail isn't hidden, implementers must know and are
> expected to understand it to make sure that it is set the zero.
>
> Because this detail isn't hidden, how appropriate is it to use this
> knowledge to advantage? If a certain task gets a facility and locks up,
> preventing any other use of it, causing dead-lock, a watcher task
> could stop
> that task and initialize (zero) the variable. Is this abusing
> implementation specific details?

Facility variables (in fact, the entire multitasker) are peculiar to SwiftX
(and its predecessors), and not anything generic or standard in Forth.
There are very specific rules about how they're to be used, including the
requirement for initialization to zero. So I wouldn't put that in the
category of implementation details that you aren't supposed to take
advantage of (an example of that class would be the use of the return stack
for DO ... LOOP indices). I see absolutely nothing wrong with making use of
info provided in the specification.

> Another implementation detail about facility variables is that the value
> they hold is the task base address. It is impossible for a task to have a
> base address of -1. Knowing this, a facility variable could be
> initialized
> to -1 at compile time to prevent all tasks from using it until
> the facility
> device is initialized. The word that initializes the device could
> initialize (zero) the facility variable. That seems like a clean
> and simple
> way to manage facility start-up, but is it abusing implementation specific
> details?

Well, again, that's simply using the specification. Personally, I'd prefer
just to initialize them to zero, but see nothing intrinsically wrong with
what you're doing beyond it being extra work for a minimal benefit.

Cheers,
Elizabeth

============================================
Elizabeth D. Rather
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. Fax: +1 310-978-9454
Suite 1018 (US & Canada) 800-55-FORTH
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time applications since 1973."
============================================

----------------------------------------------------------------------
swiftx_at_forth.com The SwiftX programming discussion email list
To unsubscribe, send subject "unsubscribe" to swiftx-request_at_forth.com
For list command help, send subject "help" to swiftx-request_at_forth.com
Message archives are located at http://www.forth.com/archive/swiftx
----------------------------------------------------------------------
This list is a forum for SwiftX users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Tue Jul 12 2005 - 21:12:09 PDT