لغة ممثل CAL

📅 آخر تحديث: ٢٤ يوليو ٢٠٢٦
✍️ نُشر في: ٢٤ يوليو ٢٠٢٦
الموسوعة الحرة

لغة CAL ( لغة ممثل CAL ) هي لغة برمجة عالية المستوى [ 1 ] لكتابة ممثلي تدفق البيانات ، وهم عبارة عن عوامل تشغيل ذات حالة تحول تدفقات إدخال كائنات البيانات (الرموز) إلى تدفقات إخراج . تم تجميع CAL لمجموعة متنوعة من المنصات المستهدفة، بما في ذلك المعالجات أحادية النواة، والمعالجات متعددة النوى، والأجهزة القابلة للبرمجة . وقد استُخدمت في العديد من مجالات التطبيق، بما في ذلك الفيديو والمعالجة والضغط والتشفير . وقد اعتمدت مجموعة عمل ترميز الفيديو القابل لإعادة التكوين (RVC) التابعة لـ MPEG [ 2 ] لغة CAL كجزء من جهودها في وضع المعايير التقنية .

التاريخ والمقدمة

طُوِّرت لغة CAL Actor Language في عام 2001 كجزء من مشروع Ptolemy II في جامعة كاليفورنيا، بيركلي . وتُعدّ CAL لغةً لتدفق البيانات مُصممة لمجموعة متنوعة من مجالات التطبيق، مثل معالجة الوسائط المتعددة، وأنظمة التحكم، ومعالجة الشبكات ، وغيرها.

من الأسباب الشائعة الأخرى لاختيار تدفق البيانات هو تحقيق تنفيذ متوازٍ فعال، وهو أمر يصعب أو يستحيل تحقيقه باستخدام لغة برمجة تسلسلية. تُعرف اللغات التسلسلية بصعوبة موازاتها عمومًا، لذا تتطلب عمليات التنفيذ المتوازية الفعالة عادةً توجيهًا كبيرًا من المستخدم. يوفر برنامج تدفق البيانات CAL تجريدات بسيطة وواضحة وقوية تسمح بتحديد مستوى التوازي المطلوب، مما يُمكّن الأدوات من إنتاج تطبيقات متطورة تستغل البنية المتزامنة للحساب.

عند البرمجة باستخدام تدفق البيانات، يقوم المبرمج عادةً بإنشاء وصف متزامن لنظام حسابي، وهو ما يختلف عن البرنامج التسلسلي التقليدي. فبدلاً من التركيز على التنفيذ خطوة بخطوة للخوارزمية ، يبني مبرمج تدفق البيانات نظامًا من الكيانات المتصلة بشكل غير متزامن، والتي تُسمى "الجهات الفاعلة". ويُوجَّه جزء كبير من جهد البرمجة نحو إيجاد طريقة مثلى لتقسيم المشكلة إلى جهات فاعلة، ونحو هندسة أنماط اتصال مناسبة بين هذه الجهات.

ميزات CAL

هيكل الفاعلين

تُجري العناصر عملياتها الحسابية في سلسلة من الخطوات تُسمى عمليات التشغيل. في كل خطوة من هذه الخطوات، قد يقوم العنصر بما يلي:

  1. استهلك الرموز من منافذ الإدخال الخاصة به
  2. قم بتعديل حالته الداخلية
  3. قم بإنتاج الرموز المميزة عند منافذ الإخراج الخاصة بها

وبالتالي، يتضمن وصف الممثل وصف واجهته الخارجية ومنافذه، وبنية حالته الداخلية، والخطوات التي يمكنه تنفيذها، ووظيفة هذه الخطوات (في إنتاج الرموز واستهلاكها، وتحديث حالة الممثل)، وكيفية اختيار الخطوة التالية التي سينفذها الممثل . يناقش هذا القسم بعض البنى في لغة CAL التي تعالج هذه المسائل. تصف الإجراءات ما يحدث خلال خطوة يقوم بها الممثل. من الصحيح القول إن الخطوة تتكون من تنفيذ إجراء. عندما يقوم الممثل بخطوة، قد يستهلك رموز الإدخال وينتج رموز الإخراج.

لذلك، تقوم أنماط الإدخال بما يلي:

  • حدد عدد الرموز المميزة (لكل منفذ) التي سيتم استهلاكها عند تنفيذ إجراء (تشغيله).
  • قم بتعريف الرموز المتغيرة التي يتم من خلالها الإشارة إلى الرموز المميزة التي يتم استهلاكها بواسطة تنفيذ إجراء ما داخل الإجراء.
  • حدد شرط إطلاق النار لأي إجراء، أي الشرط الذي يجب تحقيقه حتى يتمكن الإجراء من الإطلاق.

يُعدّ جانب الإخراج في الإجراء أبسط قليلاً، حيث تُحدّد تعابير الإخراج عدد وقيم رموز الإخراج التي سيتم إنتاجها على كل منفذ إخراج عند كل تنفيذ للإجراء. يجوز حذف التسمية الصريحة للمنفذ الذي ينطبق عليه نمط الإدخال أو تعبير الإخراج إذا كان الإجراء يُوفّر عددًا من أنماط الإدخال مساويًا لعدد منافذ الإدخال، أو عددًا من تعابير الإخراج مساويًا لعدد منافذ الإخراج. في هذه الحالة، تتم مطابقة الأنماط أو التعابير حسب موقعها مع تعريفات المنافذ.

إحدى طرق النظر إلى الممثل هي اعتباره مُشغِّلاً على تدفقات البيانات؛ حيث تدخل سلاسل من الرموز إليه عبر منافذ الإدخال، وتخرج منه عبر منافذ الإخراج. عند مناقشة آلية عمل الممثل، من المفيد غالبًا النظر إليه كمُشغِّل على التدفقات. يمكن أن تحتوي الممثلات على مُعاملات . تعمل هذه المُعاملات كثوابت أثناء تنفيذ الممثل، وتُعطى قيمة مُحددة عند إنشاء الممثل كجزء من شبكة ممثلين. الغرض الرئيسي من مُعاملات الممثل هو تمكين المبرمجين من تحديد مجموعات من الممثلين ذوي الصلة، دون الحاجة إلى تكرار الكثير من التعليمات البرمجية.

اللا حتمية

الممثل غير الحتمي هو الممثل الذي يسمح، لنفس تسلسلات الإدخال، بأكثر من عملية تشغيل وأكثر من مخرج محتمل. يمكن أن يكون عدم الحتمية فعالاً للغاية عند استخدامه بشكل مناسب، ولكنه قد يكون أيضاً مصدراً مزعجاً للأخطاء. أحد المخاوف هو إمكانية إدخال عدم الحتمية إلى الممثل دون قصد، أي أن يعتقد المؤلف أن الممثل حتمي حتى لو لم يكن كذلك. كان أحد الأهداف الرئيسية لتصميم لغة CAL هو السماح بوصف الممثلين غير الحتميين، مع السماح في الوقت نفسه للأدوات بتحديد المصادر المحتملة لعدم الحتمية، حتى تتمكن من التنبيه إليها.

من أهم نتائج استخدام مُعامل غير حتمي مثل NDMerge أن مخرجاته أثناء التنفيذ قد تعتمد على توقيت مدخلاته. فإذا كانت قائمتي المدخلات فارغتين، وكان NDMerge ينتظر مدخلات، فقد تُنسخ المدخلات التي يصلها الرمز المميز التالي إلى المخرجات. وبالتالي، قد يؤثر جدولة الأنشطة في شبكة المُعاملات، أو السرعات النسبية للمُعاملات التي تُغذي مُعاملًا مثل NDMerge، على مخرجات النظام. قد يكون هذا مرغوبًا فيه أحيانًا، وغير مرغوب فيه في أحيان أخرى. على أي حال، هي خاصية يجب أخذها في الاعتبار.

إحدى طرق فهم عدم الحتمية، من النوع الذي يجعل الفاعل معتمدًا على التوقيت الدقيق لوصول الرموز، هي أن هذا الفاعل يبدو غير حتمي فقط عند النظر إليه كعامل على تدفقات البيانات، لأن هذه النظرة تتجاهل الخصائص الزمنية للتنفيذ، وبالتالي تزيل عمدًا المعلومات المستخدمة لتحديد تسلسل تنفيذ الإجراءات. من منظور لغة CAL، هذا ليس دقيقًا تمامًا، ولكن مع ذلك، من السهل كتابة فاعلين غير حتميين لن يكونوا حتميين حتى لو كان كل شيء معروفًا عن توقيت الرموز وتنفيذ الفاعل، مثل:

تصرفات حذرة

يحتوي شرط الحماية لأي إجراء على مجموعة من الشروط التي يجب أن تتحقق جميعها حتى يكون الإجراء قابلاً للتنفيذ. لكي يكون الإجراء الأول قابلاً للتنفيذ، يجب أن يكون الرمز المميز الوارد أكبر من أو يساوي صفرًا، وفي هذه الحالة يُرسل إلى المخرج P. وإلا فلن يتمكن هذا الإجراء من التنفيذ. وعلى العكس، لكي يكون الإجراء الثاني قابلاً للتنفيذ، يجب أن يكون الرمز المميز أقل من صفر، وفي هذه الحالة يُرسل إلى المخرج N. قد يبدو تشغيل هذا الممثل كما يلي: قد يواجه الممثل مشكلة إذا صادف رمزًا مميزًا بقيمة صفر، لأنه لن يتمكن أي من إجراءاته من التنفيذ عليه.

ليس من غير القانوني كتابة برامج تتوقف عند إدخال بيانات معينة، وقد يكون من المهم وجود عدد قليل منها في بعض الأنظمة. لكن هذا يمثل مأزقًا قد يسبب مشاكل. ثانيًا، شروط الحماية غير مترابطة بالإضافة إلى كونها شاملة.

أخيرًا، يمكن لشروط الحماية الاطلاع على الرموز الواردة دون استهلاكها. إذا كانت شروط الحماية خاطئة أو لم يتم تنفيذ الإجراء لسبب آخر، وإذا لم يتم استهلاك الرمز بواسطة إجراء آخر، فإنه يبقى في مكانه، ويكون متاحًا للتنفيذ التالي. (أو يمكن أن يبقى هناك إلى أجل غير مسمى، كما هو الحال مع الرمز الصفري أمام SplitDead ، والذي لا يُزال أبدًا لأن الشخصية ميتة).

يُعدّ عنصر Select الموضح أدناه مثالًا آخر على استخدام الإجراءات المحمية. وهو مشابه لعنصر NDMerge من حيث أنه يدمج تدفقين (التدفقين الواصلين إلى منفذي الإدخال A وB). إلا أنه يفعل ذلك وفقًا للقيم المنطقية (Boolean) للرموز المميزة الواصلة إلى منفذ الإدخال S.

الجهات الفاعلة ذات الدولة

في جميع الشخصيات التي تم التعامل معها حتى الآن، لا يؤثر أي إجراء يتم تنفيذه على عمليات تنفيذ الإجراءات اللاحقة لنفس الشخصية. باستخدام متغيرات الحالة ، يمكن لعمليات تنفيذ الإجراءات أن تترك معلومات لعمليات التنفيذ اللاحقة، سواءً لنفس الإجراء أو لإجراء مختلف لنفس الشخصية. في هذه الشخصية، تُعتبر عملية اختيار رمز الإدخال التالي ثم نسخه إلى الإخراج خطوة واحدة متكاملة.

تُعتبر دالتا Select و IterSelect متطابقتين تقريبًا، ولكن ليس تمامًا. أولًا، تتطلب IterSelect ضعف عدد الخطوات لمعالجة نفس عدد الرموز. ثانيًا، تقرأ، وبالتالي تستهلك، رمز الإدخال S ، بغض النظر عما إذا كان رمز بيانات مطابق متوفرًا على A أو B.

الجداول الزمنية

أوضح ممثل IterSelect في القسم السابق استخدام الحالة للتحكم في اختيار الإجراءات. وهذا أمر شائع للغاية في الممارسة العملية، وتوفر لغة CAL صيغة خاصة لهذا الغرض في شكل جداول. من الناحية المفاهيمية، يمكن اعتبار الجداول بمثابة تقنين لنمط معين لاستخدام متغير الحالة؛ فهي لا تضيف شيئًا إلى اللغة من حيث التعبيرية. ويكمن الأساس المنطقي لاستخدام الجداول في أمرين:

  1. عادة ما تكون أسهل في الاستخدام وأقل عرضة للأخطاء من استخدام أي متغيرات حالة ، والعديد من الحواجز والتعيينات.
  2. يمكن للأدوات استخدام المعلومات المشفرة في الجدول الزمني بسهولة أكبر، وبالتالي التعرف على الانتظامات في الفاعل التي قد تساعدها على إنتاج رمز أكثر كفاءة، أو إجراء تحليلات أخرى تساعد في التنفيذ والتصميم.

يتكون كل انتقال حالة من ثلاثة أجزاء: الحالة الأصلية، وقائمة بعلامات الإجراءات، والحالة التالية. وقد ازداد عدد الإجراءات: فبدلاً من ثلاثة في النسخة الأصلية، تحتوي النسخة الجديدة ذات الجدول الزمني على أربعة إجراءات. والسبب هو أن الإجراء لم يعد بإمكانه تعيين الحالة التالية مباشرةً، كما كان الحال في النسخة الأصلية، حيث كانت قيمة الرمز المميز "read" تُعيّن إما 1 أو 2 للحالة التالية. في النسخة ذات الجدول الزمني، يُعدّ تعديل الحالة ضمنيًا في بنية آلة الحالة ، ويحدث بناءً على الإجراء المُنفّذ. وعليه، انتقل الشرط الذي يتحقق من قيمة الرمز المميز من داخل جسم الإجراء إلى حراس الإجراءين المُوسومين "readT " و "readF" .

الأولويات

طالما أن الإدخال مُتاح على منفذ إدخال واحد فقط، فالأمر واضح لا لبس فيه. ولكن، كما هو الحال مع NDMerge، بمجرد توفر الإدخال على كلا منفذي الإدخال، يُمكنه تنفيذ أي من الإجراءين المتاحين، ولا يوجد في مواصفات هذا الكائن ما يُرجّح اختيار أحدهما على الآخر.

لا تسمح لنا أي من بنيات اللغة الحالية بتحقيق ذلك. على عكس حالة الجداول الزمنية، التي يمكن اعتبارها مجرد تحسينات نحوية لأنها قابلة للاختزال إلى عناصر اللغة الموجودة (متغيرات الحالة، والشروط، والتخصيصات)، يتطلب هذا الوضع امتدادًا حقيقيًا: أولويات الإجراءات. الفكرة الأساسية هي إضافة بعض المتباينات التي تربط الإجراءات بأسبقية تنفيذها.

كما هو الحال مع الجداول الزمنية، تُستخدم علامات الإجراءات لتحديد الإجراءات التي سيتم الرجوع إليها لاحقًا، ولكن هذه المرة ضمن تفاوت الأولوية. تحتوي كتلة الأولوية على تفاوت واحد فقط، يربط بين الإجراء المُعلّم بـ "config" والإجراء المُعلّم بـ "process"، مما يمنح الأول الأولوية على الثاني. حتى هذا الإصدار لا يزال يعتمد بشكل كبير على التوقيت. في هذه الحالة، لا يُشترط أن يُمثل ذلك مشكلة، بل ربما يكون شرطًا أساسيًا لكي يؤدي هذا الفاعل وظيفته. ولكن بشكل عام، يجب فهم الأولويات جيدًا، خاصةً عند استخدامها كما في المثال السابق، للحصول على النتائج الصحيحة. خاصةً عندما تكون المعلومات المتعلقة بتوقيت الاتصال داخل الشبكة غامضة، فمن الأفضل على الأرجح اعتبارها توجيهات تنفيذية قوية.

البيانات والتعبيرات

ركز القسم السابق بشكل أساسي على البنى في لغة CAL المتعلقة بمفاهيم خاصة بالممثلين: إدخال وإخراج الرموز، والإجراءات، والتحكم في اختيار الإجراء ، وما إلى ذلك. يناقش هذا القسم الجوانب الأكثر شيوعًا في لغة CAL، وهي العبارات والتعبيرات المستخدمة لمعالجة كائنات البيانات والتعبير عن الخوارزميات (التسلسلية). يشبه هذا الجزء من اللغة ما هو موجود في العديد من لغات البرمجة الإجرائية (مثل C و Pascal و Java و Ada )، لذا ينصب التركيز على الجوانب التي قد تختلف قليلًا في لغة CAL.

تعابير الوجه

على عكس لغات مثل C، تُفرّق لغة CAL بشكلٍ واضح بين العبارات والتعبيرات. لكلٍّ منهما دورٌ ومعانٍ مُختلفة تمامًا، ولا يُمكن استخدامهما بشكلٍ مُتبادل. التعبير في CAL هو جزءٌ من التعليمات البرمجية التي يقتصر غرضها على حساب قيمة. أي أن للتعبير قيمة، أو أنه يُقيّم إلى قيمة. بالنسبة لمعظم التعبيرات، تعتمد القيمة التي تُقيّم إليها على قيم مُتغير واحد أو أكثر في وقت تقييم التعبير. وبما أن قيم المُتغيرات قد تتغير بمرور الوقت، فقد يكون للتعبير نفسه قيمٌ مُختلفة عند تقييمه في أوقاتٍ مُختلفة.

التعبيرات الذرية

لعلّ أهمّ التعبيرات الأساسية هي الثوابت. وهناك مجموعة أخرى من التعبيرات الأساسية وهي مراجع المتغيرات. من الناحية التركيبية، المتغير هو أيّ تسلسل من الحروف والأرقام . من أهمّ خصائص التعبيرات أنها تضمن عدم تغيير المتغيرات (كما نقول إنها لا تُحدث أيّ آثار جانبية) - وبالتالي، ضمن التعبير الواحد، ستؤدي المراجع المتعددة لنفس المتغير دائمًا إلى النتيجة نفسها.

التعبيرات المركبة البسيطة

توفر لغة CAL نوعين من المعاملات لبناء التعبيرات: أحادية وثنائية . المعامل الأحادي في CAL هو دائمًا معامل بادئة، أي أنه يظهر قبل معامله الوحيد. أما المعامل الثنائي فيظهر بين معامليه.

البيانات

في بعض النواحي، تُعدّ العبارات في لغة CAL نقيضًا للتعبيرات: فهي لا تُرجع قيمة ، ولكنها قادرة على تغيير قيم المتغيرات. ويُعدّ تغيير قيم المتغيرات جوهر العبارات. تُنفّذ العبارات بترتيب تسلسلي صارم. ما لم يُنصّ على خلاف ذلك، يتم تنفيذ العبارات بالترتيب الذي تظهر به في نص البرنامج. وهذا يعني أن أي تغييرات في المتغيرات تُحدثها عبارة ما قد تؤثر على تنفيذ العبارات اللاحقة.

تدفق التحكم

كما هو الحال في معظم لغات البرمجة الأخرى، توجد بنيات تحكم في تدفق البرنامج لتحديد ترتيب تنفيذ التعليمات البرمجية. الجزء من هذه الحلقة الذي يلي مباشرةً الكلمة المفتاحية foreach هو مولد، يشبه إلى حد كبير المولدات الموجودة في تراكيب القوائم .

فعل

  • أنماط الإدخال: تعريف المتغيرات
  • الحماية: تحديد شروط التمكين
  • تعابير الإخراج: حساب رموز الإخراج
  • الجسم: تعديل حالة الفاعل

مراجع

  1. ↑ إيكر، يوهان؛ يانيك، يورن دبليو. (1 ديسمبر 2003). تقرير لغة CAL: مواصفات لغة الفاعل CAL (تقرير). مذكرة فنية رقم UCB/ERL M03/48. كاليفورنيا: جامعة كاليفورنيا، بيركلي .
  2. ↑ بهاتاشاريا، شوفرا س.؛ إيكر، يوهان؛ جانيك، يورن و.؛ لوكارز، كريستوف؛ ماتافيلي، ماركو؛ روليه، ميكائيل (2009). "نظرة عامة على إطار عمل ترميز الفيديو القابل لإعادة التكوين MPEG". مجلة أنظمة معالجة الإشارات . لندن، إنجلترا: سبرينغر .