Talk:Digital Systems

From Spivey's Corner
Jump to: navigation, search

Lecture comments from Hilary Term[edit]

I've inserted responses in italic font, like this, in the hope that they might contribute to a successful final third of the course next term. Appreciative comments were gratefully received, but I've not generally responded to them explicitly. – Mike.

About the lectures[edit]

1. Do more on the operating system part.

There's more we could do, I agree, and many interesting questions to explore; but there's only so much time. Some of the issues will be expanded upon in next year's Concurrent Programming course.

2. Too many questions that require searching on the internet – interesting and fun.

Perhaps you missed some of the resources I made available to look up details: for example, the meaning of each Thumb instruction is spelled out in the ARM Architecture Reference Manual linked from the micro:bit page, and also explained in the book by Joseph Yiu that's listed. Yiu's style is not the same as mine, but that's a good thing, isn't it? If there are other things that are hard to find out, perhaps you'd let me know what they are. Did you use the opportunities to ask questions in the lectures, by adding them to the FAQ page or talk pages on the wiki, or by e-mailing them to me? If not, you missed out!

3. Felt as though the course started in the middle – could have done with a better introduction in the first lecture or two.

I always find it easier to explain things on a basis that is concrete and specific, and that's why I chose not to begin with a general overview, but to encourage participants to pick things up as we explored a growing circle of machine features and instructions. That does, I agree, leave a feeling that we are sitting in a small patch of light in the middle of a dark and mysterious forest.

4. Although [this is] a rather difficult course, [Dr] Spivey is an entertaining and informative lecturer, who explains concepts well and is clearly very passionate. One minor complaint would be that the lecture notes are sometimes lacking in detail, meaning I am often confused when answering problem sheet questions.

You think I'm passionate? How disturbing! Let me be clear about what the lecture notes are intended to be: they are the notes that I need to prepare in order to give the lecture, and I share them with the audience as an overview of what the lecture was about. They are not intended as a complete record of everything I said, and indeed sometimes what I say is determined by what questions are asked.

5. I liked the experimental nature of the lab exercises, but I think I’d be more confident with my work if the tasks were a bit more specific (for example the main task of Lab 3, felt more structured), otherwise good.

I'm not sure whether you're saying you preferred Lab 3, or preferred the others. The Lab exercises are, as you note, intentionally open-ended. Some participants chose to use quite a lot of the sessions just to practise assembly language programming, and that's fine with me. Was the problem that for Lab 2 I said, "Make the display respond to button presses," without giving explicit instructions how to do so?

6. I like that the course is taught with real hardware. We should have more discussion about potential bugs, especially concurrency related like dead locks. Pace could be faster. I would like demos to showcase bugs, bottlenecks etc.

In some ways, the lab sessions are the opportunity to carry out demonstrations. There are few things I find more irritating than lengthy sessions of watching someone fiddle about in front of an audience trying to get a result that was obvious from the start ...

7. The lectures are engaging and entertaining and concepts are not learned in detail straight away, but they are reinforced later on.

I'm glad you said this. I suppose I'm trying to give clues about what is important, and sending you off to find out the details you need to gain a feeling of understanding. The important things are ones we will first learn and then later use towards some other goal.

8. Course felt very well laid out and was at a good [pace]. Where I struggled was knowing what to write down and learn precisely for the exams. Lectures felt more like they give an understanding at topic rather than specific content to be learnt, this is fine but a little unnerving given we are yet to see any exam questions for this topic. If a good selection of [specimen] papers could be added to the website it would obviously be very useful and appreciated.

Yes, that is what lectures should be, because as a way of conveying 'specific content to be learnt' they are not at all effective. There will be specimen questions to help undergraduates and tutors to know what to expect from the exam, but the questions will be set so that they can be answered by candidates who understand the concepts.

9. A wiki is very helpful with reviewing material and also including external resources not found in lectures, but slides will be much easier to read during the lecture itself.

I will aim to use about 2 or 3 slides per lecture with diagrams or code that I don't want to write out on the board before you see it. As for the style where each paragraph becomes a slide with a handful of bullet points, see the responses I've written below.

10. Really well designed course, well explain in lectures, felt a bit ‘jumpy’ when switching around topics in the first few lectures.

I agree: we are more or less forced to choose a sequence of arbitrary-seeming programming problems in order to introduce machine instructions step by step.

11. The lecture could have introduced binary a little earlier.

My impression is that most people had a basic understanding of how binary works: it's in GCSE Computer Science after all! That's why I delayed an explicit treatment until we needed to be more precise – especially about what happens when arithmetic overflows.

12. Really good.

13. Possibly the most interest[ing] course this term. [Dr] Spivey does a fantastic job at introducing the new [topics], however, the speed of the lectures seems to remain increasing and perhaps not allowing enough time to really digest some of the concepts that have been introduced. Looking forward to next term.

... and indeed, the course continues next term, and we can explore further those things that you've had time to digest during the vac.

14. More explanation to code! Simpler homework, less theory, more practise!

I really don't know what to say in answer to this rather disturbing comment. Digital Systems is right at the 'practice' end of the spectrum of courses we offer: if it's still too theoretical for you, then I don't know what you're going to make of some of the other courses in our degree.

15. The course itself is very good and conveys a lot of knowledge. It is sometimes difficult to comprehend the lecture not having any low-level experience before. Also the problem sheets are disconnected from the lectures. Although I really like the course, I feel that it may still be improved.

Of course those participants with less prior experience are going to have to work harder: how could it be otherwise? Did you use any of the provided channels for asking questions and seeking clarification? As for the relationship between the problem sheets and the lectures, I may perceive a connection that you do not see. Does the connection become clearer after the tutorial? And would it help to add some more, simpler, exercises at the start of each problem sheet that did relate more directly to each lecture?

16. Lectures were confusing. It would have been helpful to have more structure e.g. slides. Problem sheets did not always build on lectures and were sometimes very hard to do without a lot of pre-supposed knowledge on the topic.

Thanks for clarifying this – something I have never understood before: when commenters talk about 'structure', I've always understood them to mean the large-scale structure of the course, the big argument that defines the relationship between one whole lecture and another. But now I see that there's another kind of structure on a small scale: the flow of thoughts in a single paragraph. And of course between the two is the structure of a single lecture, often stating and exploring a problem and then finding a solution, even if a later lecture modifies the solution and incorporates it into something bigger. I think what you are asking for is slides to improve the perception of structure on the small scale. The reason I rarely use them is that they would make it very difficult for me to respond during the lecture to what I get from the audience, because I would be tied to the stack of slides prepared in advance.

17. A little bit too much material was taught in short amount of time. I would have preferred if we had less material and more examples to show us how things work.

You say that there was a bit too much material, and others say the pace could have been faster: the truth is that there is no pace that suits everyone, and what I've tried to do is make sure everyone learns at least something, and maybe 80% of the class are able to follow most of it.

General comments[edit]

1. This is my favourite course this term.

2. It is also somewhat under information I need to learn and what is just specific regarding the micro bit, however I appreciate this is not an easy issue to solve given that this is the first year that course has run (with [Dr] Spivey as lecturer).

One thing that will help is that the exam paper will contain this two-page summary of Thumb instructions, published here in advance. So you will know what things you don't need to memorise because they will be there to look up.

3. The lecturer is very entertaining.

4. Perhaps utilize crochet execution to show profiling, give more insight to the how tasks are scheduled.

I really can't make sense of the first part of your comment – can you decipher it for me? As for scheduling, I think I said more about it after the lecture where the feedback was collected. Do ask via the usual channels if there's anything still unclear.

5. At the request of the lecturer, it is noted he can be childish.

I asked for that, didn't I?

An alternative instruction encoding for the ARM in which each instruction is encoded in 16 rather than 32 bits. The advantage is compact code, the disadvantage that only a selection of instructions can be encoded, and only the first 8 registers are easily accessible. In Cortex-M microcontrollers, the Thumb encoding is the only one provided.

A symbolic representation of the machine code for a program.