LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Advertise
  • Mirrors
  • Logos
  • Contact us
  • Find Resources
  • Job Opportunity
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Openrisc > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: György 'nog' Jeney<nog@j...>
    Date: Wed Jan 26 20:42:57 CET 2005
    Subject: [openrisc] [or1ksim #7] Stricter typeing...
    Top
    > > oraddr_t is used to mark addresses that the simulated processor (and
    > > peripherals) address. This is basically a reqirement to implement a 64-bit
    > > simulator (no, I'm not going to do that anytime soon). I have also defined the
    > > formating macros for these new types (PRIxADDR and PRIxREG), (What C99 has done
    > > in inttypes.h). I realise that this header and macros may not be availible on
    > > some varients of unix, but I don't know, so if you know of a place were the
    > > simulator might be used and these types are not availible, then shout and I'll
    > > stick in a configure check to fix it.
    >
    > Simulator should buid at least on Linux, Solaris, Cygwin and FreeBSD. I
    > do not think there is a need to introduce any constructs
    > that would further restrict the or1ksim portability....

    Would it suffice if I fixed the sim to compile and work if `inttypes.h' is not
    availible on the host system, or should I just drop this set of changes? Do
    you actually know that this will break on Solaris/FreeBSD or Cygwin? I just
    have this feeling that it will but I don't want to introduce hughe amounts of
    useless configure magic for nothing.

    nog.

    ReferenceAuthor
    [openrisc] [or1ksim #7] Stricter typeing...Matjaz Breskvar

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.