Gerald Dueck, Ph. D.

Associate Professor
Department of Mathematics and Computer Science

Brandon University

Publications

Dueck G. and Cormack G.V. Modular attribute grammars, Computer Journal 33:2 (1990), 164-172. ACM Portal

Burkowski F., Cormack G. and Dueck G., Architectural support for synchronous task communication,
Proc. ASPLOS III - 3rd ACM/IEEE Symposium on Architectural Support for Programming Languages and Operating Systems, in ACM SIGARCH Computer Architecture News, Volume 17 ,  Issue 2  , (1989), 40-53. ACM Portal

Dueck, Gerald, Programmer-Controlled Code Generation,
Proceedings of HICCS-20, Volume II – Software (1987), 293 – 299.

Dueck, Gerald, Experiences with a SuperPET Laboratory,
Proceedings of Canadian Information Processing Society, Ottawa, Canada, (1983), 87 – 96.

Reports and Projects

All notes, papers and websites authored by Gerald Dueck, unless otherwise noted

Light-Weight Threads: Harnessing multi-core processors, 2007 - 2009 (snapshot)

Harnessing the power of multi-core processors to increase the speed of computations
introduces overhead for synchronization and communication. This paper describes
techniques to minimize such overhead for fine-grained computations.

JNIMarshall: A Java Native Interface Generator, 2006 - 2008 (snapshot)

JniMarshall automates the task of creating marshalling code when invoking native
methods from Java. Novel features of JniMarshall include the ability to generate C++
code that performs run-time translation of Java data to and from C++ and the use of
annotations as code-generator hints. JniMarshall handles Java data structures ranging
in complexity from primitive types to mutually referential and cyclic structures.
Annotations specify structural variations, type-naming conventions, parameter direction
and string interpretations, as well as other information that cannot be inferred
from Java class definitions.

A Short Study in Two Solitudes, 2005

During the creation of a software system, participants engage in a variety of activities.
This paper describes the activities that take place in developing a computerscience
solution to a software design problem and attempts to match solution elements
to selected processes of software-engineering design. Not unexpectedly, a mismatch
occurs, which leads us to wonder about not what is common, but what is missing.

Code Management System (CMS): Research Notes, 2005

This is not a paper. It is a set of notes intended as background material for a paper.

At the CSEE&T Conference in Ottawa last April (2003), I was struck by a number of thoughts.

In her keynote address, Dr. Richardson from UC Irvine described a spectrum of activities: Electrical Engineering, Computer Engineering, Computer Science, Software Engineering, Information Technology and Information Systems. She showed how Informatics fit into this continuum spectrum. One of the questions raised during the conference was: what parts of software engineering should be taught in a traditional computer science curriculum?

There was a panel discussion with a representative from CIPS and two Professional Engineers. Some aspects of what constituted engineering — as distinct from computer science — emerged. One of these is that engineering is a profession. Here is a litmus test for “professional” that emerged from the discussion: “you cannot be considered a professional unless you can be sued.” A question arose: can non-physical products be engineered? (i.e., software systems). It appears that in order to engineer non-physical products and avoid litigation, engineers use a “process” in which “best practices” are applied at each point from initial consultation to the final software product.

There was also a session on architecture and the best ways to deal with it in the classroom.

I’ve been working on a software project with sufficient scope to challenge most students in my courses. In working through the project, I asked myself at each stage: what activity am I engaged in now? Is it architecture, computer science, software engineering, or applications development?

KModel: An object-oriented operating system design, 2005. Web site.

KModel is a working design for an operating system. It is intended as an educational tool to illustrate concepts of operating system design through review and practice.

KModel incorporates a modular monolithic kernel with devices on one side and user processes on the other. It is modular in the sense that portions of the kernel are separated and intermodule communication is controlled. It is monolithic in the sense that only one thread of control is active in the kernel at any given time, and that thread is well defined.

In part, the constraints on the kernel design stem from its language of implementation. KModel is written in Java and makes use of Java threads to provide asynchronous behaviour. Threads are used as the context for each user process. Threads are also used as the context for each device. The only use of Java thread synchronization (synchronized, wait() and notify()) is to serialize kernel entry, wakeup device threads and control user threads cum processes.

A Java-based kernel yields a different view of how kernels should be written. A kernel written in C with a disciplined approach to the use of function pointers can approximate the object-oriented style of programming, to the extent that kernel programmers are willing to embrace that philosophy. KModel is designed using object-oriented techniques including UML, Design Patterns (Gamma et. al., 1994) and componentization (Martin, 1995). It is intended that the design is more important than the detail, and that component relationships expressed in the code are self evident

Design of the Volunteer Database (Manitoba Agricultural Museum) 2003.

The volunteer-personnel database supports processes and activities at the museum, provides management information and acts as a repository for historical nformation about the operation of the museum.

This report details the database design and provides information for the roles of maintainer, user and manager. The report also provides comments on how the existence of the database impacts the processes and offers suggestions for future development.
This work was supported in part by a grant from Brandon University Community Outreach Service.

CALID: An Experimental Operating System Environment, 2001. Web site.

The Calid experimental operating system environment is, essentially, a programming language and an interpreted computer-hardware system. The programming
language is a subset of C with some features of C++. The interpreted hardware includes a processor, virtual memory, an I/O bus, and peripheral devices.
The processor is embedded in a debugger. Supporting roles are filled by additional software tools: assembler, linker, builder. The environment supports exploration of models used in operating-system design.

Older pages

The archived hierarchy starts here.