Lard Version 11 Release Notes

There are just a few minor changes in this version.

Upgrading from version 10

Existing local users will need to

• Change your .profile. All you need to change this time is the version number in LARDHOME. You should end up with something like this:

  	LARDHOME=/home/amulinks/lard/v11
  	BINFMT=`$LARDHOME/config/binfmt`
  	export LCD_OPTS="-lio -lchannels -ltime"
  	export PATH=$LARDHOME/bin/$BINFMT:$PATH
  

  As before, if you want to run the Linux and/or Solaris versions you'll also need to ensure that the following directories are in your LD_LIBRARY_PATH:
  • For Linux: /home/amulinks/lard/tcl/linux/lib
  • For Solaris: /home/amulinks/lard/tcl/sun5/lib, /usr/common/lib

• Recompile all existing programs.

Changes since version 10

• More reliable installation on Solaris

  There are a few minor changes to the installation procedure which should lead to more reliable installation on Solaris.

• Changes to the LI_LOAD_PATH environment variable

  The LI_LOAD_PATH environment variable is a colon-separated list of directories in which LARD looks for tcl modules. If it is not set, li will use a compiled in default. This has not changed.

  In the past, if you set LI_LOAD_PATH to add your own directories you had to include the location of the system tcl directories as the value of the environment variable replaced the compiled in default. This is no longer necessary as the system directory is now appended to any value specified by LI_LOAD_PATH.

• Test vector code separated out

  The test vector generation code - which is only of use to people in Manchester - is no longer part of the basic tar file.

• Test vectors for signals

  The test vector generation package now generates vectors for signals as well as channels.

• Improved tviewps module

  I have improved the functionality of the tviewps (plot) module. You can now specify a scale factor, and if you have more traces than will fit on the page the plot will be broken into multiple slices.

• Assorted bug fixes

Known Bugs

• There can be class checking problems when using an expression in the class of a declaration, for example v:var(int^(a+1)). The problem hasn't been thoroughly investigated, but is seems that it can be made to go away using an explicit eval, for example v:var(int^(eval(a+1))).

• If a recursive function's return type depends on its parameters (explicit or implicit), things will go wrong. For example, compiling the following program fails to terminate:

  (foo(T:type):expr(T)=foo(T)).null

• Multi-dimensional array declarations work "backwards", for example if I declare V:var(int^100^200) then the highest numbered element of V is V[199][99], not V[99][199] as you would have expected.

• If a channel's receiver has no delay in its ?() expression then other processes that are watching the channel using wait_until(chan_ready()) may "miss" any activity on the channel. This needs a mechanism like VHDL's delta timing model in order to get the correct behaviour.

• Bad things sometimes happen when a parameterised type declaration contains a record declaration with a field type using the parameter. This can sometimes generate bad code; under some conditions it will pick up the wrong actual value of the parameter and give a run-time error.