1 / 5

CHAIMS Compiler and Interpreter Overview

Explore the CHAIMS language compiler and interpreter, dynamic scheduler, and alternative architecture for a seamless programming experience. Learn about code generation, execution machine, network interactions, and reasons for choosing interpreter over compiler in CHAIMS language implementation. Dive into the efficiency of the dynamic scheduler, client-server communication, and flexible programming interactions within the CHAIMS ecosystem.

alaws
Download Presentation

CHAIMS Compiler and Interpreter Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Compiler: CHAIMS compiler, simple scheduler client code in C, C++, Java, stub code user megaprogram in CHAIMS language Idl-file generator and compiler executable client (CSRT) C++, Java compiler and linker network Interpreter: user CHAIMS execution machine (interpreter and scheduler) completemegaprogram in CHAIMS language serves as input to CHAIMS-protocol user some CHAIMS statements serve as input to network Interpreter instead of Compiler CHAIMS

  2. Reasons for Interpreter • Dynamic scheduler: • Input is parsed and stored in a dependency graph. • Execution machine (interpreter / scheduler) works through the graph and makes appropriate calls: • estimate-calls are added in order to get necessary run-time information for scheduling (cost-function) • every invocation is issued as soon as possible (data-flow) and reasonable (according to cost-function) • all invocations for which the CSRT waits for results are polled regularly, and results extracted and new invocations issued as soon as possible CSRT would still be sequential! • Overview results, flexible interactions: • composer can program statement by statement; immediate results can influence subsequent programming • like ftp, web CHAIMS

  3. Current Architecture: Several Implementations of PAM Client C P A M - protocols CORBA-idl DCE-idl Java-class W r a p p e r s M e g a m o d u l e s CHAIMS

  4. Alternative Architecture:Other Approach to Heterogeneity Client client site e.g. TCP/IP sockets or RMI CPAM different wrapper site RMI wrapper CORBA wrapper RMI wrapper sites of servers CORBA RMI server-specific protocols native server 1 native server 2 native server 3 chaims compliant module chaims I/O module CHAIMS

  5. Reasons for Alternative Architecture Overall: • Simpler architecture: less wrappers, just one protocol on client side Server-side: • Dataflow-optimization: direct messages within CPAM layer between megamodules/their wrappers possible without bridges Client-side: • Thin client that could run everywhere (TCP/IP or RMI are available everywhere, but not CORBA or DCE). • Implementation of the CSRT by interpreter instead of compiler is easier. • Already now we use just transport-facility of different distribution systems. CHAIMS

More Related