source: rtems/cpukit/score/cpu/m32c/rtems/score/cpu.h @ 27bfcd8

5
Last change on this file since 27bfcd8 was 27bfcd8, checked in by Sebastian Huber <sebastian.huber@…>, on Jan 25, 2017 at 1:32:02 PM

score: Delete _CPU_Context_Fp_start()

Since the FP area pointer is passed by reference in
_CPU_Context_Initialize_fp() the optional FP area adjustment via
_CPU_Context_Fp_start() is superfluous. It is also wrong with respect
to memory management, e.g. pointer passed to _Workspace_Free() may be
not the one returned by _Workspace_Allocate().

Close #1400.

  • Property mode set to 100644
File size: 30.0 KB
Line 
1/**
2 * @file
3 *
4 * @brief M32C CPU Dependent Source
5 */
6
7/*
8 *  This include file contains information pertaining to the XXX
9 *  processor.
10 *
11 *  @note This file is part of a porting template that is intended
12 *  to be used as the starting point when porting RTEMS to a new
13 *  CPU family.  The following needs to be done when using this as
14 *  the starting point for a new port:
15 *
16 *  + Anywhere there is an XXX, it should be replaced
17 *    with information about the CPU family being ported to.
18 *
19 *  + At the end of each comment section, there is a heading which
20 *    says "Port Specific Information:".  When porting to RTEMS,
21 *    add CPU family specific information in this section
22 */
23
24/*
25 *  COPYRIGHT (c) 1989-2008.
26 *  On-Line Applications Research Corporation (OAR).
27 *
28 *  The license and distribution terms for this file may be
29 *  found in the file LICENSE in this distribution or at
30 *  http://www.rtems.org/license/LICENSE.
31 */
32
33#ifndef _RTEMS_SCORE_CPU_H
34#define _RTEMS_SCORE_CPU_H
35
36#ifdef __cplusplus
37extern "C" {
38#endif
39
40#include <rtems/score/types.h>
41#include <rtems/score/m32c.h>
42
43/* conditional compilation parameters */
44
45#define RTEMS_USE_16_BIT_OBJECT
46
47/**
48 * Does RTEMS manage a dedicated interrupt stack in software?
49 *
50 * If TRUE, then a stack is allocated in @ref _ISR_Handler_initialization.
51 * If FALSE, nothing is done.
52 *
53 * If the CPU supports a dedicated interrupt stack in hardware,
54 * then it is generally the responsibility of the BSP to allocate it
55 * and set it up.
56 *
57 * If the CPU does not support a dedicated interrupt stack, then
58 * the porter has two options: (1) execute interrupts on the
59 * stack of the interrupted task, and (2) have RTEMS manage a dedicated
60 * interrupt stack.
61 *
62 * If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
63 *
64 * Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
65 * @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
66 * possible that both are FALSE for a particular CPU.  Although it
67 * is unclear what that would imply about the interrupt processing
68 * procedure on that CPU.
69 *
70 * Port Specific Information:
71 *
72 * XXX document implementation including references if appropriate
73 */
74#define CPU_HAS_SOFTWARE_INTERRUPT_STACK FALSE
75
76/**
77 * Does the CPU follow the simple vectored interrupt model?
78 *
79 * If TRUE, then RTEMS allocates the vector table it internally manages.
80 * If FALSE, then the BSP is assumed to allocate and manage the vector
81 * table
82 *
83 * Port Specific Information:
84 *
85 * XXX document implementation including references if appropriate
86 */
87#define CPU_SIMPLE_VECTORED_INTERRUPTS TRUE
88
89/**
90 * Does this CPU have hardware support for a dedicated interrupt stack?
91 *
92 * If TRUE, then it must be installed during initialization.
93 * If FALSE, then no installation is performed.
94 *
95 * If this is TRUE, @ref CPU_ALLOCATE_INTERRUPT_STACK should also be TRUE.
96 *
97 * Only one of @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK and
98 * @ref CPU_HAS_HARDWARE_INTERRUPT_STACK should be set to TRUE.  It is
99 * possible that both are FALSE for a particular CPU.  Although it
100 * is unclear what that would imply about the interrupt processing
101 * procedure on that CPU.
102 *
103 * Port Specific Information:
104 *
105 * XXX document implementation including references if appropriate
106 */
107#define CPU_HAS_HARDWARE_INTERRUPT_STACK TRUE
108
109/**
110 * Does RTEMS allocate a dedicated interrupt stack in the Interrupt Manager?
111 *
112 * If TRUE, then the memory is allocated during initialization.
113 * If FALSE, then the memory is allocated during initialization.
114 *
115 * This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE.
116 *
117 * Port Specific Information:
118 *
119 * XXX document implementation including references if appropriate
120 */
121#define CPU_ALLOCATE_INTERRUPT_STACK TRUE
122
123/**
124 * Does the RTEMS invoke the user's ISR with the vector number and
125 * a pointer to the saved interrupt frame (1) or just the vector
126 * number (0)?
127 *
128 * Port Specific Information:
129 *
130 * XXX document implementation including references if appropriate
131 */
132#define CPU_ISR_PASSES_FRAME_POINTER FALSE
133
134/**
135 * @def CPU_HARDWARE_FP
136 *
137 * Does the CPU have hardware floating point?
138 *
139 * If TRUE, then the RTEMS_FLOATING_POINT task attribute is supported.
140 * If FALSE, then the RTEMS_FLOATING_POINT task attribute is ignored.
141 *
142 * If there is a FP coprocessor such as the i387 or mc68881, then
143 * the answer is TRUE.
144 *
145 * The macro name "M32C_HAS_FPU" should be made CPU specific.
146 * It indicates whether or not this CPU model has FP support.  For
147 * example, it would be possible to have an i386_nofp CPU model
148 * which set this to false to indicate that you have an i386 without
149 * an i387 and wish to leave floating point support out of RTEMS.
150 */
151
152/**
153 * @def CPU_SOFTWARE_FP
154 *
155 * Does the CPU have no hardware floating point and GCC provides a
156 * software floating point implementation which must be context
157 * switched?
158 *
159 * This feature conditional is used to indicate whether or not there
160 * is software implemented floating point that must be context
161 * switched.  The determination of whether or not this applies
162 * is very tool specific and the state saved/restored is also
163 * compiler specific.
164 *
165 * Port Specific Information:
166 *
167 * XXX document implementation including references if appropriate
168 */
169#if ( M32C_HAS_FPU == 1 )
170#define CPU_HARDWARE_FP     TRUE
171#else
172#define CPU_HARDWARE_FP     FALSE
173#endif
174#define CPU_SOFTWARE_FP     FALSE
175
176#define CPU_CONTEXT_FP_SIZE 0
177
178/**
179 * Are all tasks RTEMS_FLOATING_POINT tasks implicitly?
180 *
181 * If TRUE, then the RTEMS_FLOATING_POINT task attribute is assumed.
182 * If FALSE, then the RTEMS_FLOATING_POINT task attribute is followed.
183 *
184 * So far, the only CPUs in which this option has been used are the
185 * HP PA-RISC and PowerPC.  On the PA-RISC, The HP C compiler and
186 * gcc both implicitly used the floating point registers to perform
187 * integer multiplies.  Similarly, the PowerPC port of gcc has been
188 * seen to allocate floating point local variables and touch the FPU
189 * even when the flow through a subroutine (like vfprintf()) might
190 * not use floating point formats.
191 *
192 * If a function which you would not think utilize the FP unit DOES,
193 * then one can not easily predict which tasks will use the FP hardware.
194 * In this case, this option should be TRUE.
195 *
196 * If @ref CPU_HARDWARE_FP is FALSE, then this should be FALSE as well.
197 *
198 * Port Specific Information:
199 *
200 * XXX document implementation including references if appropriate
201 */
202#define CPU_ALL_TASKS_ARE_FP     TRUE
203
204/**
205 * Should the IDLE task have a floating point context?
206 *
207 * If TRUE, then the IDLE task is created as a RTEMS_FLOATING_POINT task
208 * and it has a floating point context which is switched in and out.
209 * If FALSE, then the IDLE task does not have a floating point context.
210 *
211 * Setting this to TRUE negatively impacts the time required to preempt
212 * the IDLE task from an interrupt because the floating point context
213 * must be saved as part of the preemption.
214 *
215 * Port Specific Information:
216 *
217 * XXX document implementation including references if appropriate
218 */
219#define CPU_IDLE_TASK_IS_FP      FALSE
220
221/**
222 * Should the saving of the floating point registers be deferred
223 * until a context switch is made to another different floating point
224 * task?
225 *
226 * If TRUE, then the floating point context will not be stored until
227 * necessary.  It will remain in the floating point registers and not
228 * disturned until another floating point task is switched to.
229 *
230 * If FALSE, then the floating point context is saved when a floating
231 * point task is switched out and restored when the next floating point
232 * task is restored.  The state of the floating point registers between
233 * those two operations is not specified.
234 *
235 * If the floating point context does NOT have to be saved as part of
236 * interrupt dispatching, then it should be safe to set this to TRUE.
237 *
238 * Setting this flag to TRUE results in using a different algorithm
239 * for deciding when to save and restore the floating point context.
240 * The deferred FP switch algorithm minimizes the number of times
241 * the FP context is saved and restored.  The FP context is not saved
242 * until a context switch is made to another, different FP task.
243 * Thus in a system with only one FP task, the FP context will never
244 * be saved or restored.
245 *
246 * Port Specific Information:
247 *
248 * XXX document implementation including references if appropriate
249 */
250#define CPU_USE_DEFERRED_FP_SWITCH       TRUE
251
252#define CPU_ENABLE_ROBUST_THREAD_DISPATCH FALSE
253
254/**
255 * Does this port provide a CPU dependent IDLE task implementation?
256 *
257 * If TRUE, then the routine @ref _CPU_Thread_Idle_body
258 * must be provided and is the default IDLE thread body instead of
259 * @ref _CPU_Thread_Idle_body.
260 *
261 * If FALSE, then use the generic IDLE thread body if the BSP does
262 * not provide one.
263 *
264 * This is intended to allow for supporting processors which have
265 * a low power or idle mode.  When the IDLE thread is executed, then
266 * the CPU can be powered down.
267 *
268 * The order of precedence for selecting the IDLE thread body is:
269 *
270 *   -#  BSP provided
271 *   -#  CPU dependent (if provided)
272 *   -#  generic (if no BSP and no CPU dependent)
273 *
274 * Port Specific Information:
275 *
276 * XXX document implementation including references if appropriate
277 */
278#define CPU_PROVIDES_IDLE_THREAD_BODY    TRUE
279
280/**
281 * Does the stack grow up (toward higher addresses) or down
282 * (toward lower addresses)?
283 *
284 * If TRUE, then the grows upward.
285 * If FALSE, then the grows toward smaller addresses.
286 *
287 * Port Specific Information:
288 *
289 * XXX document implementation including references if appropriate
290 */
291#define CPU_STACK_GROWS_UP               TRUE
292
293/* FIXME: Is this the right value? */
294#define CPU_CACHE_LINE_BYTES 2
295
296#define CPU_STRUCTURE_ALIGNMENT RTEMS_ALIGNED( CPU_CACHE_LINE_BYTES )
297
298/**
299 * @ingroup CPUInterrupt
300 *
301 * The following defines the number of bits actually used in the
302 * interrupt field of the task mode.  How those bits map to the
303 * CPU interrupt levels is defined by the routine @ref _CPU_ISR_Set_level.
304 *
305 * Port Specific Information:
306 *
307 * XXX document implementation including references if appropriate
308 */
309#define CPU_MODES_INTERRUPT_MASK   0x00000001
310
311#define CPU_MAXIMUM_PROCESSORS 32
312
313/*
314 *  Processor defined structures required for cpukit/score.
315 *
316 *  Port Specific Information:
317 *
318 *  XXX document implementation including references if appropriate
319 */
320
321/* may need to put some structures here.  */
322
323/**
324 * @defgroup CPUContext Processor Dependent Context Management
325 *
326 * From the highest level viewpoint, there are 2 types of context to save.
327 *
328 *    -# Interrupt registers to save
329 *    -# Task level registers to save
330 *
331 * Since RTEMS handles integer and floating point contexts separately, this
332 * means we have the following 3 context items:
333 *
334 *    -# task level context stuff::  Context_Control
335 *    -# floating point task stuff:: Context_Control_fp
336 *    -# special interrupt level context :: CPU_Interrupt_frame
337 *
338 * On some processors, it is cost-effective to save only the callee
339 * preserved registers during a task context switch.  This means
340 * that the ISR code needs to save those registers which do not
341 * persist across function calls.  It is not mandatory to make this
342 * distinctions between the caller/callee saves registers for the
343 * purpose of minimizing context saved during task switch and on interrupts.
344 * If the cost of saving extra registers is minimal, simplicity is the
345 * choice.  Save the same context on interrupt entry as for tasks in
346 * this case.
347 *
348 * Additionally, if gdb is to be made aware of RTEMS tasks for this CPU, then
349 * care should be used in designing the context area.
350 *
351 * On some CPUs with hardware floating point support, the Context_Control_fp
352 * structure will not be used or it simply consist of an array of a
353 * fixed number of bytes.   This is done when the floating point context
354 * is dumped by a "FP save context" type instruction and the format
355 * is not really defined by the CPU.  In this case, there is no need
356 * to figure out the exact format -- only the size.  Of course, although
357 * this is enough information for RTEMS, it is probably not enough for
358 * a debugger such as gdb.  But that is another problem.
359 *
360 * Port Specific Information:
361 *
362 * XXX document implementation including references if appropriate
363 */
364/**@{**/
365
366/**
367 * @ingroup Management
368 *
369 * This defines the minimal set of integer and processor state registers
370 * that must be saved during a voluntary context switch from one thread
371 * to another.
372 */
373typedef struct {
374  /** This will contain the stack pointer. */
375  uint32_t sp;
376  /** This will contain the frame base pointer. */
377  uint32_t fb;
378} Context_Control;
379
380/**
381 * @ingroup Management
382 *
383 * This macro returns the stack pointer associated with @a _context.
384 *
385 * @param[in] _context is the thread context area to access
386 *
387 * @return This method returns the stack pointer.
388 */
389#define _CPU_Context_Get_SP( _context ) \
390  (_context)->sp
391
392/**
393 * @ingroup Management
394 *
395 * This defines the set of integer and processor state registers that must
396 * be saved during an interrupt.  This set does not include any which are
397 * in @ref Context_Control.
398 */
399typedef struct {
400    /**
401     * This field is a hint that a port will have a number of integer
402     * registers that need to be saved when an interrupt occurs or
403     * when a context switch occurs at the end of an ISR.
404     */
405    uint32_t   special_interrupt_register;
406} CPU_Interrupt_frame;
407
408/** @} */
409
410/**
411 * @defgroup CPUInterrupt Processor Dependent Interrupt Management
412 *
413 * On some CPUs, RTEMS supports a software managed interrupt stack.
414 * This stack is allocated by the Interrupt Manager and the switch
415 * is performed in @ref _ISR_Handler.  These variables contain pointers
416 * to the lowest and highest addresses in the chunk of memory allocated
417 * for the interrupt stack.  Since it is unknown whether the stack
418 * grows up or down (in general), this give the CPU dependent
419 * code the option of picking the version it wants to use.
420 *
421 * NOTE: These two variables are required if the macro
422 *       @ref CPU_HAS_SOFTWARE_INTERRUPT_STACK is defined as TRUE.
423 *
424 * Port Specific Information:
425 *
426 * XXX document implementation including references if appropriate
427 *
428 */
429/**@{**/
430
431/*
432 *  Nothing prevents the porter from declaring more CPU specific variables.
433 *
434 *  Port Specific Information:
435 *
436 *  XXX document implementation including references if appropriate
437 */
438
439/* XXX: if needed, put more variables here */
440
441/**
442 * Amount of extra stack (above minimum stack size) required by
443 * MPCI receive server thread.  Remember that in a multiprocessor
444 * system this thread must exist and be able to process all directives.
445 *
446 * Port Specific Information:
447 *
448 * XXX document implementation including references if appropriate
449 */
450#define CPU_MPCI_RECEIVE_SERVER_EXTRA_STACK 0
451
452/**
453 * This defines the number of entries in the @ref _ISR_Vector_table managed
454 * by RTEMS.
455 *
456 * Port Specific Information:
457 *
458 * XXX document implementation including references if appropriate
459 */
460#define CPU_INTERRUPT_NUMBER_OF_VECTORS      32
461
462/** This defines the highest interrupt vector number for this port. */
463#define CPU_INTERRUPT_MAXIMUM_VECTOR_NUMBER  (CPU_INTERRUPT_NUMBER_OF_VECTORS - 1)
464
465/**
466 * This is defined if the port has a special way to report the ISR nesting
467 * level.  Most ports maintain the variable @a _ISR_Nest_level.
468 */
469#define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
470
471/** @} */
472
473/**
474 * @ingroup CPUContext
475 *
476 * Should be large enough to run all RTEMS tests.  This ensures
477 * that a "reasonable" small application should not have any problems.
478 *
479 * Port Specific Information:
480 *
481 * XXX document implementation including references if appropriate
482 */
483#define CPU_STACK_MINIMUM_SIZE          (2048L)
484
485#ifdef __m32cm_cpu__
486  #define CPU_SIZEOF_POINTER 4
487#else
488  #define CPU_SIZEOF_POINTER 2
489#endif
490
491/**
492 * CPU's worst alignment requirement for data types on a byte boundary.  This
493 * alignment does not take into account the requirements for the stack.
494 *
495 * Port Specific Information:
496 *
497 * XXX document implementation including references if appropriate
498 */
499#define CPU_ALIGNMENT              2
500
501/**
502 * This number corresponds to the byte alignment requirement for the
503 * heap handler.  This alignment requirement may be stricter than that
504 * for the data types alignment specified by @ref CPU_ALIGNMENT.  It is
505 * common for the heap to follow the same alignment requirement as
506 * @ref CPU_ALIGNMENT.  If the @ref CPU_ALIGNMENT is strict enough for
507 * the heap, then this should be set to @ref CPU_ALIGNMENT.
508 *
509 * NOTE:  This does not have to be a power of 2 although it should be
510 *        a multiple of 2 greater than or equal to 2.  The requirement
511 *        to be a multiple of 2 is because the heap uses the least
512 *        significant field of the front and back flags to indicate
513 *        that a block is in use or free.  So you do not want any odd
514 *        length blocks really putting length data in that bit.
515 *
516 *        On byte oriented architectures, @ref CPU_HEAP_ALIGNMENT normally will
517 *        have to be greater or equal to than @ref CPU_ALIGNMENT to ensure that
518 *        elements allocated from the heap meet all restrictions.
519 *
520 * Port Specific Information:
521 *
522 * XXX document implementation including references if appropriate
523 */
524#define CPU_HEAP_ALIGNMENT         4
525
526/**
527 * This number corresponds to the byte alignment requirement for memory
528 * buffers allocated by the partition manager.  This alignment requirement
529 * may be stricter than that for the data types alignment specified by
530 * @ref CPU_ALIGNMENT.  It is common for the partition to follow the same
531 * alignment requirement as @ref CPU_ALIGNMENT.  If the @ref CPU_ALIGNMENT is
532 * strict enough for the partition, then this should be set to
533 * @ref CPU_ALIGNMENT.
534 *
535 * NOTE:  This does not have to be a power of 2.  It does have to
536 *        be greater or equal to than @ref CPU_ALIGNMENT.
537 *
538 * Port Specific Information:
539 *
540 * XXX document implementation including references if appropriate
541 */
542#define CPU_PARTITION_ALIGNMENT    CPU_ALIGNMENT
543
544/**
545 * This number corresponds to the byte alignment requirement for the
546 * stack.  This alignment requirement may be stricter than that for the
547 * data types alignment specified by @ref CPU_ALIGNMENT.  If the
548 * @ref CPU_ALIGNMENT is strict enough for the stack, then this should be
549 * set to 0.
550 *
551 * NOTE: This must be a power of 2 either 0 or greater than @ref CPU_ALIGNMENT.
552 *
553 * Port Specific Information:
554 *
555 * XXX document implementation including references if appropriate
556 */
557#define CPU_STACK_ALIGNMENT        0
558
559/*
560 *  ISR handler macros
561 */
562
563/**
564 * @ingroup CPUInterrupt
565 *
566 * Support routine to initialize the RTEMS vector table after it is allocated.
567 *
568 * Port Specific Information:
569 *
570 * XXX document implementation including references if appropriate
571 */
572#define _CPU_Initialize_vectors()
573
574/**
575 * @ingroup CPUInterrupt
576 *
577 * Disable all interrupts for an RTEMS critical section.  The previous
578 * level is returned in @a _isr_cookie.
579 *
580 * @param[out] _isr_cookie will contain the previous level cookie
581 *
582 * Port Specific Information:
583 *
584 * XXX document implementation including references if appropriate
585 */
586#define _CPU_ISR_Disable( _isr_cookie ) \
587  do { \
588    int _flg; \
589    m32c_get_flg( _flg ); \
590    _isr_cookie = _flg; \
591    __asm__ volatile( "fclr I" ); \
592  } while(0)
593
594/**
595 * @ingroup CPUInterrupt
596 *
597 * Enable interrupts to the previous level (returned by _CPU_ISR_Disable).
598 * This indicates the end of an RTEMS critical section.  The parameter
599 * @a _isr_cookie is not modified.
600 *
601 * @param[in] _isr_cookie contain the previous level cookie
602 *
603 * Port Specific Information:
604 *
605 * XXX document implementation including references if appropriate
606 */
607#define _CPU_ISR_Enable(_isr_cookie) \
608  do { \
609    int _flg = (int) (_isr_cookie); \
610    m32c_set_flg( _flg ); \
611  } while(0)
612
613/**
614 * @ingroup CPUInterrupt
615 *
616 * This temporarily restores the interrupt to @a _isr_cookie before immediately
617 * disabling them again.  This is used to divide long RTEMS critical
618 * sections into two or more parts.  The parameter @a _isr_cookie is not
619 * modified.
620 *
621 * @param[in] _isr_cookie contain the previous level cookie
622 *
623 * Port Specific Information:
624 *
625 * XXX document implementation including references if appropriate
626 */
627#define _CPU_ISR_Flash( _isr_cookie ) \
628  do { \
629    int _flg = (int) (_isr_cookie); \
630    m32c_set_flg( _flg ); \
631    __asm__ volatile( "fclr I" ); \
632  } while(0)
633
634RTEMS_INLINE_ROUTINE bool _CPU_ISR_Is_enabled( uint32_t level )
635{
636  return ( level & 0x40 ) != 0;
637}
638
639/**
640 * @ingroup CPUInterrupt
641 *
642 * This routine and @ref _CPU_ISR_Get_level
643 * Map the interrupt level in task mode onto the hardware that the CPU
644 * actually provides.  Currently, interrupt levels which do not
645 * map onto the CPU in a generic fashion are undefined.  Someday,
646 * it would be nice if these were "mapped" by the application
647 * via a callout.  For example, m68k has 8 levels 0 - 7, levels
648 * 8 - 255 would be available for bsp/application specific meaning.
649 *This could be used to manage a programmable interrupt controller
650 * via the rtems_task_mode directive.
651 *
652 * Port Specific Information:
653 *
654 * XXX document implementation including references if appropriate
655 */
656#define _CPU_ISR_Set_level( _new_level ) \
657  do { \
658    if (_new_level) __asm__ volatile( "fclr I" ); \
659    else            __asm__ volatile( "fset I" ); \
660  } while(0)
661
662/**
663 * @ingroup CPUInterrupt
664 *
665 * Return the current interrupt disable level for this task in
666 * the format used by the interrupt level portion of the task mode.
667 *
668 * NOTE: This routine usually must be implemented as a subroutine.
669 *
670 * Port Specific Information:
671 *
672 * XXX document implementation including references if appropriate
673 */
674uint32_t   _CPU_ISR_Get_level( void );
675
676/* end of ISR handler macros */
677
678/* Context handler macros */
679
680/**
681 * @ingroup CPUContext
682 *
683 * Initialize the context to a state suitable for starting a
684 * task after a context restore operation.  Generally, this
685 * involves:
686 *
687 *    - setting a starting address
688 *    - preparing the stack
689 *    - preparing the stack and frame pointers
690 *    - setting the proper interrupt level in the context
691 *    - initializing the floating point context
692 *
693 * This routine generally does not set any unnecessary register
694 * in the context.  The state of the "general data" registers is
695 * undefined at task start time.
696 *
697 * @param[in] _the_context is the context structure to be initialized
698 * @param[in] _stack_base is the lowest physical address of this task's stack
699 * @param[in] _size is the size of this task's stack
700 * @param[in] _isr is the interrupt disable level
701 * @param[in] _entry_point is the thread's entry point.  This is
702 *        always @a _Thread_Handler
703 * @param[in] _is_fp is TRUE if the thread is to be a floating
704 *       point thread.  This is typically only used on CPUs where the
705 *       FPU may be easily disabled by software such as on the SPARC
706 *       where the PSR contains an enable FPU bit.
707 * @param[in] tls_area is the thread-local storage (TLS) area
708 *
709 * Port Specific Information:
710 *
711 * XXX document implementation including references if appropriate
712 */
713void _CPU_Context_Initialize(
714  Context_Control  *the_context,
715  uint32_t         *stack_base,
716  size_t            size,
717  uint32_t          new_level,
718  void             *entry_point,
719  bool              is_fp,
720  void             *tls_area
721);
722
723/**
724 * This routine is responsible for somehow restarting the currently
725 * executing task.  If you are lucky, then all that is necessary
726 * is restoring the context.  Otherwise, there will need to be
727 * a special assembly routine which does something special in this
728 * case.  For many ports, simply adding a label to the restore path
729 * of @ref _CPU_Context_switch will work.  On other ports, it may be
730 * possibly to load a few arguments and jump to the restore path. It will
731 * not work if restarting self conflicts with the stack frame
732 * assumptions of restoring a context.
733 *
734 * Port Specific Information:
735 *
736 * XXX document implementation including references if appropriate
737 */
738void _CPU_Context_Restart_self(
739  Context_Control  *the_context
740) RTEMS_NO_RETURN;
741
742/**
743 * This routine initializes the FP context area passed to it to.
744 * There are a few standard ways in which to initialize the
745 * floating point context.  The code included for this macro assumes
746 * that this is a CPU in which a "initial" FP context was saved into
747 * @a _CPU_Null_fp_context and it simply copies it to the destination
748 * context passed to it.
749 *
750 * Other floating point context save/restore models include:
751 *   -# not doing anything, and
752 *   -# putting a "null FP status word" in the correct place in the FP context.
753 *
754 * @param[in] _destination is the floating point context area
755 *
756 * Port Specific Information:
757 *
758 * XXX document implementation including references if appropriate
759 */
760#define _CPU_Context_Initialize_fp( _destination ) \
761  { \
762   *(*(_destination)) = _CPU_Null_fp_context; \
763  }
764
765/* end of Context handler macros */
766
767/* Fatal Error manager macros */
768
769/**
770 * This routine copies _error into a known place -- typically a stack
771 * location or a register, optionally disables interrupts, and
772 * halts/stops the CPU.
773 *
774 * Port Specific Information:
775 *
776 * XXX document implementation including references if appropriate
777 */
778#define _CPU_Fatal_halt( _source, _error ) \
779  { \
780  }
781
782/* end of Fatal Error manager macros */
783
784#define CPU_USE_GENERIC_BITFIELD_CODE TRUE
785
786/* functions */
787
788/**
789 * This routine performs CPU dependent initialization.
790 *
791 * Port Specific Information:
792 *
793 * XXX document implementation including references if appropriate
794 */
795void _CPU_Initialize(void);
796
797/**
798 * @ingroup CPUInterrupt
799 *
800 * This routine installs a "raw" interrupt handler directly into the
801 * processor's vector table.
802 *
803 * @param[in] vector is the vector number
804 * @param[in] new_handler is the raw ISR handler to install
805 * @param[in] old_handler is the previously installed ISR Handler
806 *
807 * Port Specific Information:
808 *
809 * XXX document implementation including references if appropriate
810 */
811void _CPU_ISR_install_raw_handler(
812  uint32_t    vector,
813  proc_ptr    new_handler,
814  proc_ptr   *old_handler
815);
816
817/**
818 * @ingroup CPUInterrupt
819 *
820 * This routine installs an interrupt vector.
821 *
822 * @param[in] vector is the vector number
823 * @param[in] new_handler is the RTEMS ISR handler to install
824 * @param[in] old_handler is the previously installed ISR Handler
825 *
826 * Port Specific Information:
827 *
828 * XXX document implementation including references if appropriate
829 */
830void _CPU_ISR_install_vector(
831  uint32_t    vector,
832  proc_ptr    new_handler,
833  proc_ptr   *old_handler
834);
835
836/**
837 * @ingroup CPUInterrupt
838 *
839 * This routine installs the hardware interrupt stack pointer.
840 *
841 * NOTE:  It need only be provided if @ref CPU_HAS_HARDWARE_INTERRUPT_STACK
842 *        is TRUE.
843 *
844 * Port Specific Information:
845 *
846 * XXX document implementation including references if appropriate
847 */
848void _CPU_Install_interrupt_stack( void );
849
850/**
851 * This routine is the CPU dependent IDLE thread body.
852 *
853 * NOTE:  It need only be provided if @ref CPU_PROVIDES_IDLE_THREAD_BODY
854 *        is TRUE.
855 *
856 * Port Specific Information:
857 *
858 * XXX document implementation including references if appropriate
859 */
860void *_CPU_Thread_Idle_body( uintptr_t ignored );
861
862/**
863 * @ingroup CPUContext
864 *
865 * This routine switches from the run context to the heir context.
866 *
867 * @param[in] run points to the context of the currently executing task
868 * @param[in] heir points to the context of the heir task
869 *
870 * Port Specific Information:
871 *
872 * XXX document implementation including references if appropriate
873 */
874void _CPU_Context_switch(
875  Context_Control  *run,
876  Context_Control  *heir
877);
878
879/**
880 * @ingroup CPUContext
881 *
882 * This routine is generally used only to restart self in an
883 * efficient manner.  It may simply be a label in @ref _CPU_Context_switch.
884 *
885 * @param[in] new_context points to the context to be restored.
886 *
887 * NOTE: May be unnecessary to reload some registers.
888 *
889 * Port Specific Information:
890 *
891 * XXX document implementation including references if appropriate
892 */
893void _CPU_Context_restore(
894  Context_Control *new_context
895) RTEMS_NO_RETURN;
896
897static inline void _CPU_Context_volatile_clobber( uintptr_t pattern )
898{
899  /* TODO */
900}
901
902static inline void _CPU_Context_validate( uintptr_t pattern )
903{
904  while (1) {
905    /* TODO */
906  }
907}
908
909/* FIXME */
910typedef CPU_Interrupt_frame CPU_Exception_frame;
911
912void _CPU_Exception_frame_print( const CPU_Exception_frame *frame );
913
914/**
915 * @ingroup CPUEndian
916 *
917 * The following routine swaps the endian format of an unsigned int.
918 * It must be static because it is referenced indirectly.
919 *
920 * This version will work on any processor, but if there is a better
921 * way for your CPU PLEASE use it.  The most common way to do this is to:
922 *
923 *    swap least significant two bytes with 16-bit rotate
924 *    swap upper and lower 16-bits
925 *    swap most significant two bytes with 16-bit rotate
926 *
927 * Some CPUs have special instructions which swap a 32-bit quantity in
928 * a single instruction (e.g. i486).  It is probably best to avoid
929 * an "endian swapping control bit" in the CPU.  One good reason is
930 * that interrupts would probably have to be disabled to ensure that
931 * an interrupt does not try to access the same "chunk" with the wrong
932 * endian.  Another good reason is that on some CPUs, the endian bit
933 * endianness for ALL fetches -- both code and data -- so the code
934 * will be fetched incorrectly.
935 *
936 * @param[in] value is the value to be swapped
937 * @return the value after being endian swapped
938 *
939 * Port Specific Information:
940 *
941 * XXX document implementation including references if appropriate
942 */
943static inline uint32_t CPU_swap_u32(
944  uint32_t value
945)
946{
947  uint32_t byte1, byte2, byte3, byte4, swapped;
948
949  byte4 = (value >> 24) & 0xff;
950  byte3 = (value >> 16) & 0xff;
951  byte2 = (value >> 8)  & 0xff;
952  byte1 =  value        & 0xff;
953
954  swapped = (byte1 << 24) | (byte2 << 16) | (byte3 << 8) | byte4;
955  return swapped;
956}
957
958/**
959 * @ingroup CPUEndian
960 *
961 * This routine swaps a 16 bir quantity.
962 *
963 * @param[in] value is the value to be swapped
964 * @return the value after being endian swapped
965 */
966#define CPU_swap_u16( value ) \
967  (((value&0xff) << 8) | ((value >> 8)&0xff))
968
969typedef uint32_t CPU_Counter_ticks;
970
971CPU_Counter_ticks _CPU_Counter_read( void );
972
973static inline CPU_Counter_ticks _CPU_Counter_difference(
974  CPU_Counter_ticks second,
975  CPU_Counter_ticks first
976)
977{
978  return second - first;
979}
980
981#ifdef __cplusplus
982}
983#endif
984
985#endif
Note: See TracBrowser for help on using the repository browser.