-A A +A

CS2013-Strawman-AR-Architecture and Organization (DEPRECATED)

8 posts / 0 new
Last post
sahami
CS2013-Strawman-AR-Architecture and Organization (DEPRECATED)

The CS2013 Strawman Report comment period is now closed. Please see the CS2013 Ironman report for the latest CS2013 draft to comment on. Forum to comment on "AR-Architecture and Organization" Knowledge Area in the CS2013 Strawman report. We ask that comments related to specific text in the report please specify the page number and line number(s) of the text being commented on. Line numbers are provided on the far left-hand side of the each page.

alan_fekete
Balance of importance in AR
field_vote: 
0
Your rating: None

I think that a general CS graduate will find it much more useful to have an overview knowledge of multiprocessor architecture (AR/Multiprocessing and alternative architecures), rather than the older circuit level (AR/Digital logic and digital systems). In line with a top-down approach (as in Bryant and O'Hallaron's text "Computer Systems"), I would teach the level underneath the prog language runtime first, and then get into how the hardware is constructed. Thus I suggest to reallocate digital logic as entirely Elective, and take the most vital 2 hours of topics of multiprocessor systems and make that Core-Tier2 [This aslo would save one net hour from the core]

cstone
Bits, bytes, and words is Tier 2?
field_vote: 
0
Your rating: None

AR/Machine-level representation of data, page 44, line 43

I am surprised that "Bits, bytes, and words" is considered Tier 2. I understand the desire to keep Tier 1 small, but this topic seems awfully fundamental in CS.

cstone
Verilog/VHDL
field_vote: 
0
Your rating: None

AR/Digital logic and digital systems, page 43, line 30

I'm not sure I'd put "Register transfer notation/Hardware Description Language (Verilog/VHDL)" in the core, but I won't argue the point. However, it seems uncommon for Core topics to specify particular languages or tools.

sahami
Additional comments
field_vote: 
0
Your rating: None

[These comments are from Dr. David C. Dyer (Nangang Technological University, Singapore)]

In AR/Assembly level machine organization. Page 44 lines 74 to 80 inclusive.
In my opinion, many topics are missing because of ambiguous wording or potentially minimalist interpretations. I suggest the following sequence is preferable.
-Concept of a stored program and comparison of von Neumann and Harvard architectures
-Programmer's functional models including status flags
-Instruction set paradigms, classifications, mnemonics and encoding
-Control unit for instruction fetch, decode and execution
-Addressing modes
-Assembly language programming
-Mechanisms for subroutine linkage including call, return, parameters, results and local data.
-Position-independent code and recursive subroutines
-Runtime libraries to support higher-level languages, e.g. multi-word arithmetic

[An additional clarification from David Dyer:
My preferred wording was to try and capture what the informed reader may have inferred from the text in Strawman, and reduce uncertainty of interpretation for the less informed reader; always to the benefit of the students.

For example, I believe that to some (many?), the present text of "Subroutine call and return mechanisms" will appear related only to transfers of control.
This is why I wrote "Mechanisms for subroutine linkage including call, return, parameters, results and local data." so that data must also be considered.
]

2)
I understand that it is undesirable for 'Strawman' to cite any particular commercial processor(s) but there is merit in citing the specific 'intellectual property' found in processor architectures and their commercial impact. Similarly, for 'softcore' processors in Field Programmable Gate Arrays.

blahedo
Call stack... cross-reference
field_vote: 
0
Your rating: None

When I was looking through the document for "structure of the call stack", or the idea of a call stack at all, I found a partial fit in AR/Assembly level machine organization (p 44) with "Subroutine call and return mechanisms" (line 80), but was dissatisfied. I eventually found what I was looking for under PL/Language Translation and Execution (p 132, line 128); it's not necessarily a problem that the topic falls into PL rather than AR, but there should probably be a cross-reference.

sahami
Additional comments (received via email)
field_vote: 
0
Your rating: None

Machine level representation of data – looks very traditional – what about multimedia data (sound, graphics, video, photographs, etc) Perhaps covered elsewhere? Cross refer?

Error correcting codes? Link to fault tolerance, a systems concept?

I might have expected a section on devices – thus cameras, iPhone (and so synchronising with devices in various ways), intelligent cities; link to security issues associated with mobility

hemmendd
AR topics
field_vote: 
0
Your rating: None

P 44, ll 53-57 (Data representations) bits, number bases, and numeric and non-numeric representations are basic to understanding information and finite storage, and should be in Tier 1.

P 43, ll 25-31 (Digital logic) This is too much for three hours. The section could cover the basics of combinational and sequential logic -- e.g. multiplexers, adders, registers -- and their physical realizations; also informal register-transfer notation -- assignment, sequential and concurrent operations.. FPGAs, CAD tools, and HDLs are important for computer engineering, but not for a brief CS overview.

It would be good to have a little more in the core on high-performance architectures: pipelining, ILP, multiprocessors, as another comment said. Much of the Interfacing section (p 46) is also addressed in the Networking, OS, and Parallel Processing sections of the core; could the AR interfacing section be shortened to make a little more room for these other topics?

Log in or register to post comments