Languages, Compilers, Tools and Theory of Embedded SystemsLCTES 2025

LCTES 2025

Welcome to the 26th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, and Tools for Embedded Systems (LCTES 2025)!

LCTES provides a link between the programming languages and embedded systems engineering communities. Researchers and developers in these areas are addressing many similar problems but with different backgrounds and approaches. LCTES is intended to expose researchers and developers from either area to relevant work and interesting problems in the other area and provide a forum where they can interact.

LCTES 2025 is co-located with and shares the venue and activities with PLDI 2025.

The important dates are as follows:

• Paper Submission Deadline: March 14, 2025 March 21, 2025 (extended firm deadline)
• Paper Notification: April 21, 2025
• Artifact Evaluation Submission Deadline: April 28, 2025
• Artifact Evaluation Notification: May 9, 2025
• Camera-Ready Deadline: May 12, 2025
• Conference Dates: June 16–17, 2025

Conference Hotel Group Rate Ending Soon

The discounted group rate for conference hotel accommodations will expire on Sunday, May 25th, 2025.

Please book your room promptly to secure this special rate via this link.

Important Visa Information for Attendees

The Korean Consulate has confirmed that a Short-Term Tourism Visa (C-3-9) is sufficient to attend LCTES 2025. However, if your local Korean Consulate does not accept the C-3-9 visa application for conference attendance, please apply for a Short-Term General Visa (C-3-1) instead. For C-3-1 visa applications, we can provide the following documents:

• Official invitation letter (from the PLDI general chair)
• Business certificate of the conference hotel (from the PLDI general chair)
• Visa support letter (from ACM, should be requested during registration)

Please contact the PLDI general chair via the contact form with your name and affiliation to request these documents.

LCTES 2025 Registration is now open!

Click here to find registration page, fees and agenda.

You can request a visa support letter during registration.

Click here to see our hotel group rate for PLDI 2025.

Accepted Papers

Call for Artifacts

Submission Site

Submit your artifacts through https://lctes2025ae.hotcrp.com.

• Artifact Submission Deadline: 11:59 pm Apr 28, 2025 (AoE)
• Artifact Decision Notification: May 9, 2025

General Info

The authors of all accepted LCTES papers (including WIP papers) are invited to submit supporting materials to the Artifact Evaluation process. Artifact Evaluation is run by a separate Artifact Evaluation Committee (AEC) whose task is to assess how well the artifacts support the work described in the papers. This submission is voluntary but strongly encouraged and will not influence the final decision regarding the papers.

At LCTES, we follow ACM’s artifact review and badging policy, version 1.1. ACM describes a research artifact as follows:

By “artifact” we mean a digital object created by the authors to be used as part of the study or generated by the experiment itself. For example, artifacts can be software systems, scripts used to run experiments, input datasets, raw data collected in the experiment, or scripts used to analyze results.

Submission of an artifact does not imply automatic permission to make its content public. AEC members will be instructed that they may not publicize any part of the submitted artifacts during or after completing the evaluation, and they will not retain any part of any artifact after evaluation. Thus, you can include models, data files, proprietary binaries, and similar items in your artifact.

We expect each artifact to receive three reviews. Papers that pass the Artifact Evaluation process will receive up to three ACM artifact evaluation badge(s) directly printed on the paper and available as meta information in the ACM Digital Library.

Artifact evaluation is single-blind. Please take precautions (e.g., turning off analytics and logging) to help prevent accidentally learning the reviewers’ identities.

Badging

The papers with accepted artifacts will be assigned official ACM artifact evaluation badges based on the criteria defined by ACM. The AEC awards up to three types of badges that reflect the evaluation (red), availability (green), and validation (blue) of the artifact and the results of the paper. Refer to the ACM website for detailed badge information. Note that artifacts will be evaluated with respect to the claims and presentation in the submitted version of the paper, not the camera-ready version.

The awarded badges will appear on the first page of the camera-ready version of the paper. Artifact authors will be allowed to revise their camera-ready paper after being notified of their artifact’s publication to include a link to the artifact’s DOI.

Note that we only award the “Reproducibility” (dark blue) badge but not the “Replication” (light blue) one.

Guidelines

1. Carefully think which badge(s) you seek to receive.
   • If your only goal is to publish your code, seek the “Availability” (green) badge. The reviewers will not exercise the artifact for its functionality or validate the paper’s claims.
   • If you wish you have your results reproduced without making your artifact documented, consistent, complete, and exercisable, seek the “Reproducibility” (blue) badge rather than the “Functionality/Reusability” (red) badge.
   • If you do not want to make the artifact available publicly, do not seek the “Availability” (green) badge.
2. Minimize the artifact setup overhead.
   • A well-packaged artifact is easily usable by the reviewers and conveys the value of your work. A great way to package an artifact is as a VM image or Docker container that runs “out of the box.” We encourage authors to include pre-built binaries along with the source and build scripts that allow the AEC to regenerate the binaries to guarantee maximum transparency. Pre-built VM or docker images are preferred over scripts that build the image since this alleviates reliance on external dependencies. Make sure to test your artifact on at least one machine different than the one you used to prepare the artifact to identify missing dependencies.
   • Giving AE reviewers remote access to your machines with preinstalled (proprietary) software is possible.

Preparing the Artifact

You should make your artifact available as a single archive file and use the naming convention <paper #>.<suffix>, where the appropriate suffix is used for the given archive format. Use a commonly-available compressed archive format such as .tgz, .tbz2, or .zip and open document formats. The link to download your artifact must protect the anonymity of the reviewers (e.g., a Google Drive URL).

The compressed archive should consist of three pieces:

1. The submitted version of your accepted paper.
2. A README file (PDF or plaintext format) that explains your artifact (details below).
3. A folder containing the artifact.

The README.txt should consist of two parts:

1. A Getting Started Guide and
2. Step-by-Step Instructions that detail how your artifact can be evaluated. Include appropriate references to the relevant sections of your paper.

The Getting Started Guide should contain instructions on how to set up (including, for example, a pointer to the VM player software, its version, and passwords if needed) and test your artifact. Anyone following this guide should be able to handle the rest of your artifact easily.

The Step-by-Step Instructions explain how to reproduce experiments or other activities supporting your paper’s conclusions. Write this for readers who are deeply interested in your work and are studying to improve or compare against it. If your artifact runs for more than a few minutes, point this out and explain how to run it on smaller inputs.

Where appropriate, include descriptions of and links to files (included in the archive) that represent the expected outputs such as log files generated by your tool for a given set of inputs. If there are warnings that can be ignored, explain what they are.

Further, include the following:

• A list of claims from the paper supported by the artifact. Explain how and why the artifact supports those claims.
• A list of claims from the paper not supported by the artifact. Explain why the artifact does not support those claims. Examples: performance claims cannot be reproduced in a VM, authors cannot redistribute specific benchmarks, etc.

When preparing your artifact, please keep in mind:

• How accessible you are making your artifact to other researchers.
• The AEC members will have a limited time to assess your artifact.

Artifact Evaluation Committee

Other than the chair, the AEC members are senior graduate students, postdocs, or recent Ph.D. graduates, identified with the help of the LCTES PC and recent artifact evaluation committees. Please check SIGPLAN’s Empirical Evaluation Guidelines for some methodologies to consider during evaluation.

Throughout the review period, reviews will be submitted to HotCRP and continuously visible to authors. AEC reviewers will be able to continuously interact (anonymously) with authors for clarifications, system-specific patches, and other logistics to help ensure that the artifact can be evaluated. Continuous interaction prevents rejecting artifacts for “wrong library version” types of problems.

Our goal is that all submitted artifacts successfully pass the artifact evaluation.

Call for Papers

Programming languages, compilers, and tools are important interfaces between embedded systems and emerging applications in the real world. Embedded systems are aggressively adapted for deep neural network applications, large language models, autonomous vehicles, robots, healthcare applications, etc. However, these emerging applications impose challenges that conflict with conventional design requirements and increase the complexity of embedded system designs. Furthermore, they exploit new hardware paradigms to scale up multicores (including GPUs and FPGAs) and distributed systems built from many cores. Therefore, programming languages, compilers, and tools are becoming more important to address these issues, such as productivity, validation, verification, maintainability, safety, and reliability for meeting both performance goals and resource constraints.

The 26th ACM SIGPLAN/SIGBED International Conference on Languages, Compilers, Tools and Theory of Embedded Systems (LCTES 2025) solicits papers presenting original work on programming languages, compilers, tools, theory, and architectures that help in overcoming these challenges. Research papers on innovative techniques are welcome, as well as experience papers on insights obtained by experimenting with real-world systems and applications. Papers can be submitted to https://lctes2025.hotcrp.com/.

Important Dates

• Abstract Submission: March 7, 2025 March 14, 2025 (soft, new submission is open until March 14, 2025 March 21, 2025)
• Paper Submission: March 14, 2025 March 21, 2025 (extended firm deadline)
• Paper Notification: April 21, 2025
• Artifact Evaluation Submission: April 28, 2025
• Artifact Evaluation Notification: May 9, 2025
• Camera-Ready Submission: May 12, 2025
• Conference Dates: June 16–17, 2025

Paper Categories

• Full paper: 10 pages presenting original work (at most 2 additional pages for references and appendix).
• Poster, work-in-progress and invited paper: 4 pages papers presenting original ideas that are likely to trigger interesting discussions.
• Accepted papers in both categories will appear in the proceedings published by ACM. In addition, this year’s LCTES will have Distinguished Paper awards selected from this year’s accepted paper to recognize the outstanding work among all papers.

Special Issue Invitation

Accepted full papers will be invited to submit to a special issue of the ACM Transactions on Embedded Computing Systems (TECS). A TECS publication will require substantial additional material over the conference publication and will undergo a separate review process. Papers submitted to LCTES (including the WIP papers) will be welcome to submit manuscripts to a special issue of the IEEE Embedded Systems Letters (IEEE ESL). A 4-page IEEE ESL manuscript will require clearly distinct intellectual contribution as compared to the conference paper and will undergo a separate review process.

Topics

Original contributions are solicited on the topics of interest including, but not limited to:

Programming language challenges

• Domain-specific languages
• Features to exploit multicore, reconfigurable, and other emerging architectures
• Features for distributed, adaptive, and real-time control embedded systems
• Capabilities for specification, composition, and construction of embedded systems
• Language features and techniques to enhance reliability, verifiability, and security
• Virtual machines, concurrency, inter-processor synchronization, and memory management
• Compiler challenges

Interaction between embedded architectures, operating systems, and compilers

• Interpreters, binary translation, just-in-time compilation, and split compilation
• Support for enhanced programmer productivity
• Support for enhanced debugging, profiling, and exception/interrupt handling
• Optimization for low power/energy, code/data size, and real-time performance
• Parameterized and structural compiler design space exploration and auto-tuning
• Tools for analysis, specification, design, and implementation, including:
• Hardware, system software, application software, and their interfaces
• Distributed real-time control, media players, and reconfigurable architectures
• System integration and testing
• Performance estimation, monitoring, and tuning
• Run-time system support for embedded systems
• Design space exploration tools
• Support for system security and system-level reliability
• Approaches for cross-layer system optimization
• Theory and foundations of embedded systems

Predictability of resource behavior: energy, space, time

• Validation and verification, in particular of concurrent and distributed systems
• Formal foundations of model-based design as the basis for code generation, analysis, and verification
• Mathematical foundations for embedded systems
• Models of computations for embedded applications
• Novel embedded architectures

Design and implementation of novel architectures

• Workload analysis and performance evaluation
• Architecture support for new language features, virtualization, compiler techniques, debugging tools
• Architectural features to improve power/energy, code/data size, and predictability
• Mobile systems and IoT

Operating systems for mobile and IoT devices

• Compiler and software tools for mobile and IoT systems
• Energy management for mobile and IoT devices
• Memory and IO techniques for mobile and IoT devices

Large language models (LLMs) and programming languages/compilers

• Impact of LLMs on embedded system design and architectures
• LLM-based debugging tools for embedded software
• Adapting LLMs for resource-constraint environment
• LLM for embedded systems and compilers
• LLM for program analysis, testing and verification.
• Program analysis, testing and verification for LLM

Submission

Submissions must be in ACM SIGPLAN subformat of the acmart format (available at and explained in more detail at https://www.sigplan.org/Resources/Author/). Each paper should be in 10pt font and have no more than 10 pages for full papers or 4 pages for work-in-progress papers, excluding the bibliography. There is a 2-page limit on the page count for references. Each reference must list all authors of the paper (do not use et al.). The citations should be in numeric style, e.g., [52]. Submissions must be in PDF format and printable on US Letter and A4-sized paper. For papers in the work-in-progress category, add the suffix “(WIP)” to your title, such as “Title (WIP)”.

To enable double-blind reviewing, submissions must adhere to two rules:

• author names and their affiliations must be omitted; and,
• references to related work by the authors should be in the third person (e.g., not “We build on our previous work …” but rather “We build on the work of …”).

However, nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). Papers must describe unpublished work that is not currently submitted for publication elsewhere as discussed here. Authors of accepted papers will be required to sign an ACM copyright release.

ACM Publications Policies

1. By submitting your article to an ACM Publication, you are hereby acknowledging that you and your co-authors are subject to all ACM Publications Policies, including ACM’s new Publications Policy on Research Involving Human Participants and Subjects. Alleged violations of this policy or any ACM Publications Policy will be investigated by ACM and may result in a full retraction of your paper, in addition to other potential penalties, as per ACM Publications Policy.

2. Please ensure that you and your co-authors obtain an ORCID ID, so you can complete the publishing process for your accepted paper. ACM has been involved in ORCID from the start, and we have recently made a commitment to collect ORCID IDs from all of our published authors. The collection process has started and will roll out as a requirement throughout 2022. We are committed to improve author discoverability, ensure proper attribution and contribute to ongoing community efforts around name normalization; your ORCID ID will help in these efforts.

AUTHORS TAKE NOTE

The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work.

By submitting the paper, the authors agree that if the paper is accepted, one author will have to register at the conference rate and present the paper in person at the LCTES 2025 conference.

Submission site

https://lctes2025.hotcrp.com

This document is for those presenting a paper at LCTES ’25. If you’re presenting at ISMM, PLDI, or PLDI tutorial/workshop, please see the Speaker’s Guide on the page for the corresponding conference/track.

Congratulations on having your paper accepted at LCTES ’25! This document will help ensure your presentation runs smoothly and has the best possible audience impact. Please read it in its entirety.

Checklist

Before LCTES:

• Prepare and practice.
• Each regular paper’s presentation slot lasts for 20 minutes, including 17 minutes of presentation and 3 minutes of Q&A.
• Each WIP paper’s presentation slot lasts for 10 minutes, including 7 minutes of presentation and 3 minutes of Q&A.
• Check the program to establish when and where your talk will be.
• Ensure you have an HDMI adaptor for your device.

Before your talk:

• Familiarize yourself with the room you will be speaking in.
• Find and introduce yourself to your session chair.
• Ensure that you are in the room no later than 5 minutes before your session.

After your talk:

• Expect questions from the floor and the session chair.

Preparing Your Talk

Your work will have a greater impact if you’re well prepared.

It is very important that you run to schedule. The LCTES ’25 schedule is extremely tight, and thus session chairs have been asked to stick rigidly to the schedule.

Guidelines

1. Your talk should run for no more than the allocated time (i.e., 17 minutes for full papers, 7 minutes for WIP papers), uninterrupted. This gives you about three minutes for questions and speaker changeover.
2. Your talk should be prepared for the standard 16:9 widescreen ratio. If your talk is in a different ratio, at best it will be pillarboxed, wasting screen real estate and diminishing impact, and at worst, it won’t display correctly.
3. You will present your talk from a lectern, using a fixed lectern mic.
4. You will need to provide your talk ahead of time in either PDF or PowerPoint.

Advices

There are many excellent sources of advice on giving good talks, including from Simon Peyton Jones, Michael Hicks, Michael Ernst, and Derek Dreyer. Make good use of these!

Q&A

If you stick to the above schedule, you will have about 3 minutes for questions. The in-room audience will be able to ask questions via a queue at a single microphone on a mic stand in the center of the room.

It is good practice, as the speaker, to repeat your understanding of the question before providing your answer. This is particularly important when time is tight because it reduces opportunities for time being wasted on account of a misunderstanding.