WEBVTT

00:00:00.000 --> 00:00:01.900 align:middle line:90%


00:00:01.900 --> 00:00:04.710 align:middle line:84%
In this video, we'll cover
the compiler in a little bit

00:00:04.710 --> 00:00:08.610 align:middle line:84%
more detail, we'll talk
about how the language was

00:00:08.610 --> 00:00:12.200 align:middle line:84%
implemented, what kind of coding
restrictions you can expect,

00:00:12.200 --> 00:00:14.620 align:middle line:84%
and any calling
conventions for functions.

00:00:14.620 --> 00:00:18.530 align:middle line:90%


00:00:18.530 --> 00:00:21.310 align:middle line:84%
So let's get started with
the language implementation.

00:00:21.310 --> 00:00:23.390 align:middle line:84%
The compiler
supports C code only.

00:00:23.390 --> 00:00:28.840 align:middle line:84%
There is no support for
C++ for GCC extensions.

00:00:28.840 --> 00:00:32.159 align:middle line:84%
Data types supported on
the CLA are shown here.

00:00:32.159 --> 00:00:35.830 align:middle line:84%
Note that there are some
differences from C28,

00:00:35.830 --> 00:00:37.950 align:middle line:90%
most notably the integer.

00:00:37.950 --> 00:00:43.280 align:middle line:84%
So integers C28 and 16
bits wide, while on the CLA

00:00:43.280 --> 00:00:45.310 align:middle line:90%
they are 32 bits wide.

00:00:45.310 --> 00:00:48.140 align:middle line:84%
So this may cause a problem
if you are sharing variables

00:00:48.140 --> 00:00:50.400 align:middle line:90%
between the CLA and the C28.

00:00:50.400 --> 00:00:57.475 align:middle line:84%
If I define an array of 16 bit
integers on the C28 and I use

00:00:57.475 --> 00:01:01.300 align:middle line:84%
and modify this same
array on the CLA,

00:01:01.300 --> 00:01:06.630 align:middle line:84%
the CLA will treat them as an
array of 32 bit data types.

00:01:06.630 --> 00:01:09.690 align:middle line:84%
It does not convert them,
it just interprets them

00:01:09.690 --> 00:01:11.800 align:middle line:90%
as 32 bit data types.

00:01:11.800 --> 00:01:17.010 align:middle line:84%
So this might effectively
corrupt all subsequent data

00:01:17.010 --> 00:01:20.190 align:middle line:84%
locations from the first
location in the array.

00:01:20.190 --> 00:01:21.730 align:middle line:84%
So you have to be
very careful when

00:01:21.730 --> 00:01:27.680 align:middle line:84%
using the integer type
across CLA and the C28

00:01:27.680 --> 00:01:29.850 align:middle line:90%
at the same time.

00:01:29.850 --> 00:01:32.610 align:middle line:84%
So my advice is use
explicit data types,

00:01:32.610 --> 00:01:36.038 align:middle line:84%
like int32 or uint16 for
variable declarations.

00:01:36.038 --> 00:01:39.320 align:middle line:90%


00:01:39.320 --> 00:01:42.970 align:middle line:84%
The CLA architecture is
geared for 32-bit data type.

00:01:42.970 --> 00:01:46.600 align:middle line:84%
16-bit data types incur
sign extension overhead.

00:01:46.600 --> 00:01:49.610 align:middle line:84%
So it's probably not
best to use these

00:01:49.610 --> 00:01:53.090 align:middle line:84%
for arithmetic or
in array indexing

00:01:53.090 --> 00:01:54.780 align:middle line:90%
and those kind of operations.

00:01:54.780 --> 00:01:59.860 align:middle line:84%
If you must use them, try to
minimize their usage to load

00:01:59.860 --> 00:02:03.530 align:middle line:90%
and store operations only.

00:02:03.530 --> 00:02:07.110 align:middle line:84%
All C28 pragmas are accepted
except for the FAST_FUNC_CALL.

00:02:07.110 --> 00:02:09.880 align:middle line:90%


00:02:09.880 --> 00:02:14.350 align:middle line:84%
The C standard library
is not supported.

00:02:14.350 --> 00:02:17.410 align:middle line:84%
And finally, the keyword
cregister, far, and ioport

00:02:17.410 --> 00:02:18.608 align:middle line:90%
are also not supported.

00:02:18.608 --> 00:02:25.550 align:middle line:90%


00:02:25.550 --> 00:02:29.130 align:middle line:84%
Next, we have the
language restrictions.

00:02:29.130 --> 00:02:32.430 align:middle line:84%
The first being that defining
and initializing global data

00:02:32.430 --> 00:02:34.120 align:middle line:90%
is not supported.

00:02:34.120 --> 00:02:38.250 align:middle line:84%
The CLA does not have a runtime
support library associated

00:02:38.250 --> 00:02:40.620 align:middle line:84%
with it, so there
isn't a routine

00:02:40.620 --> 00:02:44.844 align:middle line:84%
to initialize global
data on startup.

00:02:44.844 --> 00:02:49.560 align:middle line:84%
Second, 64-bit data type
operations are not supported.

00:02:49.560 --> 00:02:53.450 align:middle line:84%
So double precision math is
definitely out of the question.

00:02:53.450 --> 00:02:57.850 align:middle line:84%
We merely define a 64-bit
data type, in this case

00:02:57.850 --> 00:03:03.360 align:middle line:84%
long double, as two contiguous
32-bit memory locations.

00:03:03.360 --> 00:03:06.490 align:middle line:84%
We do this so as to avoid
breaking compatibility

00:03:06.490 --> 00:03:15.280 align:middle line:84%
with some of the USB
code that's on the 28069.

00:03:15.280 --> 00:03:18.130 align:middle line:84%
Next, local variables
and compiler temporaries

00:03:18.130 --> 00:03:21.600 align:middle line:84%
are placed in an area that
we call the scratchpad memory

00:03:21.600 --> 00:03:23.160 align:middle line:90%
area.

00:03:23.160 --> 00:03:25.050 align:middle line:84%
It's accessed by
these two variables,

00:03:25.050 --> 00:03:27.530 align:middle line:84%
you have a start variable
and an end variable.

00:03:27.530 --> 00:03:30.630 align:middle line:84%
This section is meant solely
for use by the compiler.

00:03:30.630 --> 00:03:35.890 align:middle line:84%
The user is cautioned to avoid
using this location to store

00:03:35.890 --> 00:03:37.905 align:middle line:90%
his or her own variables.

00:03:37.905 --> 00:03:41.510 align:middle line:90%


00:03:41.510 --> 00:03:43.460 align:middle line:84%
It is expected
that you, the user,

00:03:43.460 --> 00:03:46.470 align:middle line:84%
will manage this
scratchpad area and you

00:03:46.470 --> 00:03:49.230 align:middle line:84%
will define these symbols
using a linker command file.

00:03:49.230 --> 00:03:51.051 align:middle line:84%
So this is shown
on the next slide.

00:03:51.051 --> 00:03:54.210 align:middle line:90%


00:03:54.210 --> 00:03:57.720 align:middle line:84%
This scratchpad also serves as
a CLA stack, so function calls

00:03:57.720 --> 00:04:02.450 align:middle line:84%
and returns will use this memory
location to perform context,

00:04:02.450 --> 00:04:03.458 align:middle line:90%
saves, and restores.

00:04:03.458 --> 00:04:06.150 align:middle line:90%


00:04:06.150 --> 00:04:10.240 align:middle line:84%
And this was the linker command
file I was talking about.

00:04:10.240 --> 00:04:11.777 align:middle line:84%
So right off at the
top, you can see

00:04:11.777 --> 00:04:13.360 align:middle line:84%
that we have defined
a variable that's

00:04:13.360 --> 00:04:15.680 align:middle line:90%
called CLA_SCRATCHPAD_SIZE.

00:04:15.680 --> 00:04:18.149 align:middle line:90%
And we set it equal to hex 100.

00:04:18.149 --> 00:04:22.900 align:middle line:84%
So this is where you set the
length of the scratchpad area.

00:04:22.900 --> 00:04:27.750 align:middle line:84%
Now, if you see here I have
commented this line out.

00:04:27.750 --> 00:04:31.070 align:middle line:84%
Basically there are two ways of
defining the scratchpad size,

00:04:31.070 --> 00:04:33.770 align:middle line:84%
you can either do it in the
linker command file here,

00:04:33.770 --> 00:04:35.630 align:middle line:84%
that's why I'm
commenting that line,

00:04:35.630 --> 00:04:37.330 align:middle line:84%
or you can do it
through the Build

00:04:37.330 --> 00:04:40.720 align:middle line:90%
Settings of the project in CCS.

00:04:40.720 --> 00:04:43.840 align:middle line:84%
We also allocate space
for the CLA scratchpad

00:04:43.840 --> 00:04:45.395 align:middle line:90%
in a section called CLA Scratch.

00:04:45.395 --> 00:04:49.580 align:middle line:90%


00:04:49.580 --> 00:04:52.890 align:middle line:84%
Continuing with the
language restrictions.

00:04:52.890 --> 00:04:54.580 align:middle line:84%
Function nesting,
you can only have

00:04:54.580 --> 00:04:57.380 align:middle line:90%
two levels of call stack depth.

00:04:57.380 --> 00:05:01.480 align:middle line:84%
And I will illustrate
this in the next slide.

00:05:01.480 --> 00:05:05.170 align:middle line:84%
Recursive function
calls are not supported.

00:05:05.170 --> 00:05:08.444 align:middle line:84%
Function pointers are
also not supported.

00:05:08.444 --> 00:05:10.110 align:middle line:84%
And there are some
additional operations

00:05:10.110 --> 00:05:12.140 align:middle line:84%
that are just too
expensive to implement

00:05:12.140 --> 00:05:15.580 align:middle line:84%
with the native instructions
available on the CLA,

00:05:15.580 --> 00:05:19.350 align:middle line:84%
these are namely integer
divide and modulus

00:05:19.350 --> 00:05:21.080 align:middle line:90%
and integer unsigned compares.

00:05:21.080 --> 00:05:27.660 align:middle line:90%


00:05:27.660 --> 00:05:30.360 align:middle line:84%
So this is an illustration
of the restrictions

00:05:30.360 --> 00:05:33.820 align:middle line:90%
that we have on the call depth.

00:05:33.820 --> 00:05:38.990 align:middle line:84%
So let's say we have 8 tasks
in the CLA, task 1 through 8,

00:05:38.990 --> 00:05:41.100 align:middle line:90%
and we trigger task 1.

00:05:41.100 --> 00:05:44.230 align:middle line:84%
Task 1 will hook into
the CLA math library

00:05:44.230 --> 00:05:47.310 align:middle line:90%
and call the sine function.

00:05:47.310 --> 00:05:49.750 align:middle line:90%
Sine function executes, returns.

00:05:49.750 --> 00:05:54.000 align:middle line:84%
Task 1 runs to completion
and issues an interrupt

00:05:54.000 --> 00:05:58.370 align:middle line:84%
to the C28 saying, hey, I've
finished, everything is fine.

00:05:58.370 --> 00:06:00.470 align:middle line:90%
This works perfectly fine.

00:06:00.470 --> 00:06:02.070 align:middle line:90%
Let's take a look at task 2.

00:06:02.070 --> 00:06:03.340 align:middle line:90%
It does the same thing.

00:06:03.340 --> 00:06:05.610 align:middle line:90%
The C28 triggers task 2.

00:06:05.610 --> 00:06:08.220 align:middle line:90%
Task 2 will call CLA cosine.

00:06:08.220 --> 00:06:09.980 align:middle line:90%
Cosine runs to end.

00:06:09.980 --> 00:06:12.410 align:middle line:84%
Task 2 will run to
completion and then trigger

00:06:12.410 --> 00:06:14.690 align:middle line:90%
an interrupt to the C28.

00:06:14.690 --> 00:06:16.690 align:middle line:90%
Everything is fine here as well.

00:06:16.690 --> 00:06:18.063 align:middle line:90%
Now, task 8.

00:06:18.063 --> 00:06:21.300 align:middle line:90%
The C28 will trigger task 8.

00:06:21.300 --> 00:06:24.610 align:middle line:84%
Task 8 will make a call
to a function called Foo.

00:06:24.610 --> 00:06:27.370 align:middle line:84%
Now, Foo attempts
to make another call

00:06:27.370 --> 00:06:31.710 align:middle line:84%
to a function in the
math library square root.

00:06:31.710 --> 00:06:33.200 align:middle line:90%
This is disallowed.

00:06:33.200 --> 00:06:37.640 align:middle line:84%
Basically, you're limited to
two levels of function calls.

00:06:37.640 --> 00:06:41.100 align:middle line:84%
So now if I replace
the function Foo

00:06:41.100 --> 00:06:43.957 align:middle line:84%
and it does something simple
like just return y plus,

00:06:43.957 --> 00:06:46.347 align:middle line:90%
plus, this is fine.

00:06:46.347 --> 00:06:47.680 align:middle line:90%
This will not give you an error.

00:06:47.680 --> 00:06:59.070 align:middle line:90%


00:06:59.070 --> 00:07:03.320 align:middle line:84%
The CLA compiler supports
the following intrinsics.

00:07:03.320 --> 00:07:06.050 align:middle line:84%
I won't go over these in
detail, but you can always

00:07:06.050 --> 00:07:09.570 align:middle line:84%
find out more information about
each of these from the compiler

00:07:09.570 --> 00:07:11.720 align:middle line:90%
documentation itself.

00:07:11.720 --> 00:07:13.990 align:middle line:84%
The one intrinsic that
I did want to highlight

00:07:13.990 --> 00:07:16.890 align:middle line:90%
is the mdebugstop intrinsic.

00:07:16.890 --> 00:07:20.230 align:middle line:84%
Now, on the C28,
you can actually

00:07:20.230 --> 00:07:24.270 align:middle line:84%
set a breakpoint in your
code through CCS itself.

00:07:24.270 --> 00:07:27.610 align:middle line:84%
This functionality is
not available on the CLA.

00:07:27.610 --> 00:07:31.700 align:middle line:84%
If you want to set a breakpoint
in your code in the CLA,

00:07:31.700 --> 00:07:35.500 align:middle line:84%
you actually have to
insert the mdebugstop

00:07:35.500 --> 00:07:38.280 align:middle line:84%
intrinsic at that
location in code

00:07:38.280 --> 00:07:41.100 align:middle line:84%
where you want
execution to stop.

00:07:41.100 --> 00:07:43.805 align:middle line:84%
We'll cover more about
debugging in a later tutorial.

00:07:43.805 --> 00:07:51.440 align:middle line:90%


00:07:51.440 --> 00:07:54.015 align:middle line:84%
Next, we talk about the
compiler generated sections.

00:07:54.015 --> 00:07:56.580 align:middle line:90%


00:07:56.580 --> 00:07:59.470 align:middle line:84%
Uninitialized global data
will be placed in the section

00:07:59.470 --> 00:07:59.970 align:middle line:90%
.bss_cla.

00:07:59.970 --> 00:08:03.580 align:middle line:90%


00:08:03.580 --> 00:08:06.600 align:middle line:84%
Initialized constant data
is placed in another section

00:08:06.600 --> 00:08:09.590 align:middle line:90%
called .const_cla.

00:08:09.590 --> 00:08:15.230 align:middle line:84%
An example of constant
initialized data is shown here.

00:08:15.230 --> 00:08:19.420 align:middle line:84%
| scratchpad is placed
in a memory location

00:08:19.420 --> 00:08:21.210 align:middle line:90%
called CLA Scratch.

00:08:21.210 --> 00:08:25.070 align:middle line:84%
Its size is determined by a
variable called CLA Scratchpad

00:08:25.070 --> 00:08:30.020 align:middle line:84%
Size, which we defined at the
top of our linker command file

00:08:30.020 --> 00:08:31.510 align:middle line:90%
in one of our previous slides.

00:08:31.510 --> 00:08:36.360 align:middle line:90%


00:08:36.360 --> 00:08:39.400 align:middle line:84%
So those are the three locations
that you have in the data

00:08:39.400 --> 00:08:42.809 align:middle line:84%
RAM, which we've
assigned to CLA RAM 1.

00:08:42.809 --> 00:08:47.900 align:middle line:84%
And on the actual physical
device, it resides in RAM L2.

00:08:47.900 --> 00:08:50.780 align:middle line:84%
The CLA program is
placed in a section

00:08:50.780 --> 00:08:53.247 align:middle line:90%
that we call CLA 1 Program.

00:08:53.247 --> 00:08:54.830 align:middle line:84%
This is the convention
that we've been

00:08:54.830 --> 00:08:57.260 align:middle line:90%
using for CLA assembly code.

00:08:57.260 --> 00:09:00.030 align:middle line:84%
And so this will carry over
to our C programming model

00:09:00.030 --> 00:09:01.260 align:middle line:90%
as well.

00:09:01.260 --> 00:09:03.930 align:middle line:84%
And this section
is always residing

00:09:03.930 --> 00:09:06.830 align:middle line:84%
in RAM L3 on all of our
CLA enabled devices.

00:09:06.830 --> 00:09:09.470 align:middle line:90%


00:09:09.470 --> 00:09:12.050 align:middle line:84%
As a final note,
there is no support

00:09:12.050 --> 00:09:14.870 align:middle line:84%
for operations such
as malloc or free,

00:09:14.870 --> 00:09:18.390 align:middle line:84%
so there is no need for a
C system heap for the CLA.

00:09:18.390 --> 00:09:26.660 align:middle line:90%


00:09:26.660 --> 00:09:28.650 align:middle line:84%
This is the last
part of the video

00:09:28.650 --> 00:09:31.024 align:middle line:84%
where we cover function
structure and calling

00:09:31.024 --> 00:09:31.523 align:middle line:90%
conventions.

00:09:31.523 --> 00:09:34.630 align:middle line:90%


00:09:34.630 --> 00:09:36.690 align:middle line:84%
As I've indicated
previously, the compiler

00:09:36.690 --> 00:09:40.910 align:middle line:84%
only supports two levels
of function calls.

00:09:40.910 --> 00:09:45.250 align:middle line:84%
There is a convention associated
with function arguments,

00:09:45.250 --> 00:09:48.840 align:middle line:84%
the first being that you can
only have up to two arguments.

00:09:48.840 --> 00:09:53.530 align:middle line:84%
Pointers are passed
through MAR0 and MAR1.

00:09:53.530 --> 00:09:58.600 align:middle line:84%
Integer or float arguments
are passed through MR0, MR1.

00:09:58.600 --> 00:10:01.565 align:middle line:84%
Return values that are
either integer or float

00:10:01.565 --> 00:10:03.100 align:middle line:90%
are passed an MR0.

00:10:03.100 --> 00:10:05.780 align:middle line:90%


00:10:05.780 --> 00:10:09.050 align:middle line:84%
And pointer or return by
reference values from functions

00:10:09.050 --> 00:10:10.880 align:middle line:90%
are passed in MAR0.

00:10:10.880 --> 00:10:13.940 align:middle line:90%


00:10:13.940 --> 00:10:17.690 align:middle line:84%
As far as register
saves and restores go,

00:10:17.690 --> 00:10:21.550 align:middle line:84%
all registers except for
MR3 are saved on call,

00:10:21.550 --> 00:10:24.090 align:middle line:90%
whereas MR3 is saved on entry.

00:10:24.090 --> 00:10:26.470 align:middle line:84%
This is true for
C functions only.

00:10:26.470 --> 00:10:30.700 align:middle line:84%
If you are using mixed C and
Assembly, it is up to you

00:10:30.700 --> 00:10:34.830 align:middle line:84%
to save MR3 when you enter
the function and to restore it

00:10:34.830 --> 00:10:36.390 align:middle line:90%
when you exit from the function.

00:10:36.390 --> 00:10:43.140 align:middle line:90%


00:10:43.140 --> 00:10:45.030 align:middle line:90%
Local variables.

00:10:45.030 --> 00:10:49.360 align:middle line:84%
The scratchpad is used as
a stack or a local frame

00:10:49.360 --> 00:10:52.260 align:middle line:84%
to store all the local
variables from a function.

00:10:52.260 --> 00:10:56.810 align:middle line:84%
So it is very important that
you allocate a sufficient size

00:10:56.810 --> 00:10:57.980 align:middle line:90%
for the scratchpad area.

00:10:57.980 --> 00:11:00.021 align:middle line:84%
This should make sure that
none of your variables

00:11:00.021 --> 00:11:01.120 align:middle line:90%
are corrupted.

00:11:01.120 --> 00:11:05.460 align:middle line:84%
You can do this using
the linker command file.

00:11:05.460 --> 00:11:07.000 align:middle line:84%
And a final note
is that if you're

00:11:07.000 --> 00:11:10.420 align:middle line:84%
mixing CLA C and Assembly,
it is very important

00:11:10.420 --> 00:11:12.970 align:middle line:84%
to follow the calling
conventions defined above,

00:11:12.970 --> 00:11:16.850 align:middle line:84%
especially the one where you
save and restore MR3 on entry

00:11:16.850 --> 00:11:18.292 align:middle line:90%
and exit from a function.

00:11:18.292 --> 00:11:24.960 align:middle line:90%


00:11:24.960 --> 00:11:26.700 align:middle line:90%
Thanks for watching this video.

00:11:26.700 --> 00:11:29.820 align:middle line:84%
In the next segment, we will
cover the programming model

00:11:29.820 --> 00:11:32.270 align:middle line:90%
used in all of our examples.

00:11:32.270 --> 00:11:33.232 align:middle line:90%