summaryrefslogtreecommitdiffstats
path: root/c/src/exec/score (follow)
Commit message (Collapse)AuthorAgeFilesLines
* New files from Ralf Corsepius <corsepiu@faw.uni-ulm.de>. His comments:Joel Sherrill1998-07-177-0/+330
| | | | | | | | | | | * c/src/exec/score/tools/sh - NEW DIRECTORY - contains shgen Most of it should be self-explanatory. I am a little bit concerned about host-dependent features (getopt, floating point libraries). This shouldn't disturb much now, as this tool should be compileable on all gnu-based hosts and is only applicable for the sh. But in case somebody complains, we may need to add autoconf checks or even restructurize parts of rtems (IMO, rtems needs to be restructurized - remember the "turning rtems upside down" issue).
* Fixed typo.Joel Sherrill1998-07-013-3/+3
|
* Monstrous patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>. I haveJoel Sherrill1998-06-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | made no attempt to divide the comments up and place them with just the appropriate files. Here is an excerpt from Ralf's email: Changes including comments on changes I made after cycling through all the targets: * Added ranlib support. Now all targets use "ranlib" instead of "ar -s" to build an index for a library. If ranlib isn't detected during configuration, check if ar -s is working and try "ar -s" instead of * Removed $(XXX_FOR_TARGET) from make/target.cfg.in, use $(XXX) instead now. * gcc-target-default.cfg: LINK_XXXX-defines reworked to solve the -l problem under posix (cf gcc-target-default.cfg) * rtems-glom replaced by Makefile-rules inside of the wrapup/Makefile.in that has been using rtems-glom until now. * Removed CCC and friends in gcc-target-default.cfg, as they have been breaking CXX support. * Removed CONFIG.$(TARGET_ARCH).CC lines from several custom/*.cfg files, because this is now set in custom/default.cfg. * Added aclocal/ar-s.m4, check whether "ar -s" is working * Added aclocal/cygwin.m4 and aclocal/exeext.m4. * Reworked aclocal/canonicalize-tools.m4: Added ar -s check; fixes for problems when XXX_FOR_TARGET is given via environment variables (didn't work for gcc until now), adding cygwin check, improved autoconf-cache handling. * Removed -l from make rule dependencies. LINK_LIBS is now allowed to contain -L and -l. LINK_OBJS and LINK_FILES must not contain -L or -l. gcc28 make-exe rules now link using $(LINK_OBJS) $(LINK_LIBS) => Almost all custom/*.cfg are modified. This is very likely to break something because of typos or having missed to edit a file. Open problems, known bugs, things I didn't do: * custom/p4000.cfg seems to be out of date and requires to be reviewed. (JRS NOTE: It is subordinate p4650 and p4600 -- both of which build ok after minor changes.) * custom/psim.cfg needs to be reviewed, I added some changes to it, I am insecure about. (JRS NOTE: psim had a minor problem endif/endef swapped but runs fine.) * rtems-glom.in can now be removed. * gcc*.cfg files "make depend" rules don't honor language specific flags (e.g CXXFLAGS is ignored for *.cc) - Nothing to worry about now, but may cause problems for hosts/targets not using gcc or rtems-add-ons that use external packages. * AFAIS, the no_bsp BSP can't be build anymore, i.e. configure refused to configure for it whatever I tried. * The toplevel and toplevel+1 README files are quite out-dated * cygwin.m4 isn't of much use for rtems. In most cases (cf. aclocal/*.m4) it is worked around by directly using $host_os. I think I'll remove it soon after the next snapshot * Before release the cygwin patch needs to be tested under cygwin. I may have broken/missed something (esp. the sed-pattern to convert \\ into / may be broken). * You should try to build/run the posix-BSP under solaris - I don't expect problems, but I am not 100% sure, esp. with regard to ranlib/ar -s. * You should consider to convert all make/compilers/*.cfg files into make/compilers/*.cfg.in files and let autoconf generate the *.cfg. This may help getting rid of some if/then/else statements and help hard-coding some defines into those files in future and shouldn't disturb now. * Not having installed libc.a/libm.a on a host may still break building rtems, esp. when using -disable-gcc28 as the gcc27-configuration scheme directly accesses libc.a and libm.a. The problem should not appear when using gcc28 because it references libc/libm only through -lc and -lm which may be static or dynamic (I didn't test this). * shgen is not yet included (I didn't yet have enough time to integrate it). * I know about a few more configure-probs (esp. cross-checking --enable-* flags). + warn/refuse to configure when --enable-libcdir and --enable-gcc28 are given. + force --enable-libcdir when --disable-gcc28 is given * Replaced KSHELL with @KSH@ in some shell scripts generated by configure.in. * Added a dependency to aclocal/*.m4 in the toplevel Makefile => configure and aclocal.m4 will now be rebuild when any aclocal/*.m4 file is changed * Some changes to aclocal/gcc-pipe.m4 and aclocal/gcc-specs.m4 * Replaced i[[3456]]86-unknown-freebsd2.[[12]] with i[[3456]]86-*freebsd2.* in configure.in, as I suppose there might exist a variety of valid vendors (2nd field of the name-tripple) * Disabled override MAKEFLAGS in toplevel Makefile.in - Potential side-effects are not really clear to me. * In mvme162.cfg, $(LINK_LIBS) is missing in the CC line in gcc28's make-exe rule (yet another one I missed to edit). Just append $(LINK_LIBS) to the "CC" line, like I hopefully did to ALL other custom/*.cfg files. * the problem with mvme162lx.cfg is a follow-up problem of the mvme162.cfg-bug. * mvme162/console and idp/console had variables named Buffer which conflicted with similarly named variables in some tests.
* Coldfire support patch from David Fiddes <D.J.Fiddes@hw.ac.uk>.Joel Sherrill1998-06-253-14/+151
|
* Patch from Robin Kirkham <Robin.Kirkham@mlb.dmt.csiro.au> to distinguishJoel Sherrill1998-06-251-7/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between CPU32 and CPU32+ cores. Commentary follows: Unfortunately c/src/exec/score/cpu/m68k/m68k.h incorrectly defines M68K_HAS_MISALIGNED for the plain old CPU32 (it is correct for the CPU32+). As a consequence, the recently-relocated m68k memcpy() may still attempt misaligned memory accesses. I suggest that until such time as egcs/gcc differentiates these cores that we invent a new preprocessor symbol, RTEMS__mcpu32p__ for this purpose, on the assumption that egcs may one day grow a -mcpu32+ option which will define a __mcpu32p__ symbol (whether this option would also define __mcpu32__ is yet to be resolved). BSPs that have a CPU32+ (like gen68360) would for the time being define RTEMS__mcpu32p__ using -D. The symbol is `RTEMS__mcpu32p__' because symbols of the form __xxx__ should only be defined by the compiler itself. Note that the patch tests for RTEMS__mcpu32p__ *before* __mcpu32__, since __mcpu32__ is still defined for the CPU32+. It does not change the gen68360 BSP. An aside: Note that in egcs-1.0.3a, the option -m68332 is identical to -mcpu32, except it defines __mc68332__ as well as __mcpu32__. This is only for the sake of compatibility. The story with -m68302 is similar; it defines __mc68302__ and __mc68000__. In my opinion these options are depreciated and ought to be avoided in RTEMS.
* Suggestion from Robin Kirkham <Robin.Kirkham@mlb.dmt.csiro.au> to improveJoel Sherrill1998-06-241-2/+1
| | | | clarity.
* Modified _Objects_Is_class_valid() to correctly report that 0 wasJoel Sherrill1998-06-184-4/+4
| | | | | not a valid object class. This was discovered while looking for a bug reported by Jennifer.
* Added freebsd support from Dario Alcocer <alcocer@connectnet.com>.Joel Sherrill1998-06-184-2/+27
|
* Added optimized version of memcpy.c to this directory since RTEMS makesJoel Sherrill1998-06-122-1/+88
| | | | | | important distinctions between CPU models which are not made by gcc. These distinctions help give us a more optimized memcpy(). This is important for message queues and KA9Q.
* Added CPU_ISR_PASSES_FRAME_POINTER so some ports could pass just theJoel Sherrill1998-06-0313-0/+133
| | | | | vector number to user ISR's and other ports could pass both the vector number and a pointer to the ISF.
* Corrected macros for assembly language program sections.Joel Sherrill1998-06-031-2/+2
|
* Fixed spacingJoel Sherrill1998-05-271-16/+16
|
* Fix from Jiri Gaisler <jgais@ws.estec.esa.nl> for a problem in whichJoel Sherrill1998-05-271-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | external interrupt priorities were not being honored. Here is some of his original report: using rtems/erc32, I have a problem with interrupt priority when interrupts occure simultaneously. Erc32 has an interrupt force register where interrupts can be generated. If more than one interrupt is generated, the interrupt handlers are scheduled in the wrong order, i.e. with the lowest priority first. I have attched a program that generates three interrupts, 0x11, 0x12 and 0x13. Interrupt 0x13 should be handled first, but is actually handled last. Below is the output from sis: sis> go resuming at 0x02000000 RAM size: 4096 K, ROM size: 2048 K Watchdog disabled Waitstates = RAM read: 0, RAM write: 0, ROM read: 0, ROM write: 0 Power-down mode enabled infinite UART baudrate External interrupt received with vector 0x11 External interrupt received with vector 0x12 External interrupt received with vector 0x13 I have verified that sis generates the interrupts in the correct order, i.e. 0x13 first, then 0x12 and then 0x11. So the problem seems to be in the rtems interrupt handler. Do you use the PIL field in the %psr register to mask lower priority interrupts or are all external interrupts considered to have the same priority ..? Here is a description of the fix: it turned out that lower priority interrupts were not at all masked off during interrupt handling. I made the following fix to cpu_asm.s: ... fix is in the code ... There might be a simpler way of doing this, but this works...
* Per suggestion from Ralf Corsepius made all macros solaris2 -- not solarisJoel Sherrill1998-05-211-1/+1
| | | | or solaris2.
* Added bsp_specs.Joel Sherrill1998-05-181-3/+4
|
* fixed swap of unsigned16Joel Sherrill1998-05-041-6/+6
|
* Fixed case where wrong variable was used.Joel Sherrill1998-04-301-1/+1
|
* Added I386_HAS_BSWAP cpu model feature flag so swap u32 could takeJoel Sherrill1998-04-271-10/+28
| | | | | | | | advantage of this instruction. Also up conditionals mapping cpu models to feature flags by having a section which defaults all the i386 family feature flags to the most common value.
* Added swap of unsigned16Joel Sherrill1998-04-2711-3/+69
|
* Fixed spelling errors.Joel Sherrill1998-04-271-3/+3
|
* Fixed trace bit manipulation per requests from Eric Norum and Chris Johns.Joel Sherrill1998-04-271-11/+3
| | | | Actual patch was from Eric Norum.
* Fixed CVS IdJoel Sherrill1998-04-271-1/+1
|
* Added bh, ch, dh, bl, cl, and dl register macros.Joel Sherrill1998-04-151-0/+7
|
* Per suggestion from Eric Norum, went from one initial extension setJoel Sherrill1998-04-154-18/+26
| | | | | | to multiple. This lets the stack check extension be installed at system initialization time and avoids the BSP having to even know about its existence.
* Ralf Corsepius suggested a way to get rid of UNIX compiler files and use ↵Joel Sherrill1998-04-142-2/+1
| | | | gcc-target-default.cfg
* Refreshing effort from Avenger.Joel Sherrill1998-04-148-322/+1046
|
* Added "sigemptyset()" call to insure that the memcmp() would work.Joel Sherrill1998-03-311-0/+4
| | | | | It appears that the new glibc does not clear all the bits of the signal set with a sigprocmask.
* Changed int to unsigned32 to match cpu.h.Joel Sherrill1998-03-271-1/+1
|
* m68k software interrupt stack support from Chris Johns and Eric Norum.Joel Sherrill1998-03-253-32/+36
|
* Added _XOPEN_SOURCE definition to allow use of UNIX IPC.Joel Sherrill1998-03-241-0/+1
|
* Real definition for the beginning of the data section per Eric Norum'sJoel Sherrill1998-03-241-2/+2
| | | | suggestion.
* Corrected register constraints per suggestion from Thomas Doerfler, IMDJoel Sherrill1998-03-242-6/+6
| | | | <td@imd.m.isar.de>.
* More cpu model flags converted to using cpp predefines.Joel Sherrill1998-03-241-2/+2
|
* Rename hppa1_1 to hppa1.1 and switched to using __XXX__ macros forJoel Sherrill1998-03-242-14/+14
| | | | the CPU family name constants.
* Renamed hppa1_1 to hppa1.1Joel Sherrill1998-03-231-4/+1
|
* renamed ppc to powerpcJoel Sherrill1998-03-231-1/+0
|
* Fixed spacing to be consistent with other CPUs.Joel Sherrill1998-03-211-1/+1
|
* Patch from Eric Norum <eric@skatter.usask.ca>:Joel Sherrill1998-03-201-81/+75
| | | | | | Here is my attempt at bringing m68k.h into line with the predefined symbols provided by egcs-1.0.2-prerelease (with R. Kirkham's patch so that -mcpu32, etc. implies -msoft-float).
* SH port submitted from Ralf Corsepius <corsepiu@faw.uni-ulm.de>.Joel Sherrill1998-03-2013-0/+2869
|
* Removed use of dc. David Fiddes reported that this is part of theJoel Sherrill1998-02-271-1/+17
| | | | | GNU tool bc which is not always installed under Linux and seldom present under non-UNIX environments like Win32.
* Modified to make it possible for an ISR to return a mutex which didJoel Sherrill1998-02-201-2/+20
| | | | not use priority ceiling or priority inheritance protocols.
* Ralf Corsepius noted that there was a dead path in _Thread_Initialize.Joel Sherrill1998-02-181-6/+2
|
* updated copyright to 1998Joel Sherrill1998-02-17225-229/+229
|
* Renamed init.o to exinit.o to avoid naming conflicts with tests.Joel Sherrill1998-02-171-2/+2
|
* Swapped C++ and ASM "endifs"Joel Sherrill1998-02-171-2/+2
|
* Fixed to correctly operate on target variants like debug and profile.Joel Sherrill1998-02-071-9/+23
|
* Ralf Corsepius noticed that generally was spelled incorrectly.Joel Sherrill1998-02-0411-11/+11
|
* Big patch form Ralf Corsepius described in this email:Joel Sherrill1998-01-3023-92/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here is the result of my nightly work to get RTEMS_ROOT=$srcdir working with different shells and relative/absolute paths. What I did is relatively simple in principle: Instead of setting RTEMS_ROOT in configure.in and then let configure substitute @RTEMS_ROOT@ inside the Makefiles, I now let each Makefile set RTEMS_ROOT from each Makefile's @top_srcdir@ value. The difference is subtile, but with enormous side effects: - If RTEMS_ROOT is set in configure, then the same single value will be propagated to all Makefiles. This breaks using relative paths, as the relative path to the root of the source tree is used inside of all subdirectory Makefiles. - Now each Makefile.in sets RTEMS_ROOT = @top_srcdir@. top_srcdir is computed individually by configure for each single Makefile.in, hereby receiving the correct value, no matter if relative or absolute paths are used. To get this working, I needed to remove setting RTEMS_ROOT from target.cfg.in, because this overrides the value of RTEMS_ROOT from each individual Makefile. Furthermore, I removed RTEMS_CUSTOM from the Makefiles and replaced all "include $(RTEMS_CUSTOM)" directives with"include $(RTEMS_ROOT)/make/custom/$(RTEMS_BSP)". Perhaps you don't like this, but I think, to have one variable less is clearer and easier to understand than having several variables refering to the next one. I enclose a small patch to this mail, which - fixes the config.h problem (to finally clearify misunderstands) - removes assignment/subsitution of RTEMS_ROOT from configure.in - contains a workaround for the application Makefile's RTEMS_ROOT problem (reported by Eric) - removes some unused lines from the toplevel Makefile.in - removes assignment of RTEMS_ROOT from make/target.cfg.in
* Change to remove warning on glibc2 systems per Ralf Corsepius'sJoel Sherrill1998-01-281-1/+6
| | | | suggestion.
* Solaris port updates from Chris JohnsJoel Sherrill1998-01-231-10/+0
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 10:01:21 +0000