OpenBIOS

openbios@openbios.org

4297 discussions

�°ӷ~�줽�ǥX��
by hcxc5_2gk1525＠allianz.de 09 Jun '02

09 Jun '02

********************** ¯Â°Ó·~¿ì€œ«Ç¥X¯² ********************** ±MªùªA°È°Ó¥Î¿ì€œ«Ç€§©Ó¯²€H¡C ¥x¥_ŠUµ¥¯Å°Ó¥Î¿ì€œ«Ç®×¥ó¡AŸAŠXŠUºØ°Ó·~»ÝšD¡I¡I §ÚÌŸÖŠ³ºZ³qªºžê°T¡BŠ³«ÜŠh¥ß§Yn¥X¯²ªº¿ì€œ«Ç¡A¥¿µ¥«ÝµÛ±zªº¬D¿ï¡A €@©wn¬°±z§äšì€@³B³ÌŸAŠX±z¹ê²{±z¶¯¹Ï§§§Óªº³õ©Ò¡I¡I¡I¡I Á|šÒŠp€U¡G °Ï°ì¡G €jŠw°Ï¡G €¯·Ržô¡BŽ°€Æ«n¡B¥_žô 50-300©W¡]¯²ª÷1200-2500€ž¡^¡B ¯Â¿ì®ð¬£€jŒÓ¡A²{ŠšŠÊžUžËæC¡]§K³»Åýª÷¡^¡B °š€W¥išÏ¥Î «Hžq°Ï¡G «Hžqžô€@¡B€G¡B€T¡B¥|¡B€¬q¡C 30-500©W¡]1200-2100€ž¡^ ¥þ·s®ð¬£€jŒÓ¡Bªñ±¶¹B¯ž€f¡B¥æ³q€è«K ¡]¯²ª÷ŠX²z¡B¥i±Ä³»ù¡^ ªQ€s°Ï¡G «nšÊªFžô€T¡B¥|¡B€¡B¬q 30-450©W¡]¯²ª÷1000-1800€ž¡^ ®ð¬£¡BŽºÆ[µŽšÎ €€€s°Ï¡G ªQŠ¿žô¡BªøŠwªFžô¡A€€€s¥_žô 70¢w400©W¡]¯²ª÷1000-2200€ž¡^ ¯Â¿ì¡B²{Š³žËæC Šè °Ï¡G ©Ÿ§µŠèžô¡BÀ]«ežô¡B©ÓŒwžô¡B¿Å¶§žô 50-500©W ŠÊžUžËæC¡B«K©y¥X¯²¡]Åwªï¬Ý«Î¡^ €ºŽò°Ï¡G «¹º°Ï 80-500©W1300€ž°_¡CœÐ§âŽ€š}Ÿ÷ ¥þ·s®ð¬£€jŒÓ¡B²{Š³žËæC¡B°š€W¥išÏ¥Î ªA°È²Ä€@¡A«~œè«OÃÒ¡CÅwªï¬¢žß. ·ç°T€£°Ê²£ °Ó¥ò³¡ Ápµž€H¡G³³€p©j ·q€W TeL¡]¥Nªíž¹¡^¡G 02-27492314 Šæ°Ê¹qžÜ¡G0937063831 ±zªºº¡·N¡A¬O§ÚÌªºŠšŽN¡I¡I¡I¡I - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] Defining ." and "
by Parag Patel 08 Jun '02

08 Jun '02

In message <3D020539.41212D60(a)chello.nl>, Segher Boessenkool writes: > >Where does it say it requires two? I can't find no reference to this in >the 1275 spec. The ANS, on the other hand, requires only one, and even >then only *if* you implement S" in interpreting state. Page 102 (A.2 Specification) for " and page 178 for s": "At least two temporary buffers, used alternately, shall be provided." BTW, in implementing the spec, I found I had to read each word's descriptions in detail as there's a lot of small stuff like this tucked away in the bowels of the spec. -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] Defining ." and "
by Parag Patel 08 Jun '02

08 Jun '02

In message <3D0188D6.5999ED4B(a)chello.nl>, Segher Boessenkool writes: > >1) garbage collect. ouch. >2) in dictionary or similar --> never freed >3) in "string buffers" -- either 1 or 2, but both problems >less severe. 3.5) A fixed number of static fixed-length buffers that are treated as a ring of least-recently-used buffers. The Open Firmware spec requires at least two. We typically use two buffers for " and another two for s" just to make sure that they don't step on each other. The idea is that since only two are required by the spec, all development code should be able to run with at least two, and thus increasing the number later or for a specific port won't cause portability problems (as going the other way would). -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 2

Defining ." and "
by Stefan Reinauer 07 Jun '02

07 Jun '02

Hi,.. I tried the following 2 definitions: HEX 0 > : " 22 PARSE ; IMMEDIATE ok 0 > : ." 22 PARSE TYPE ; IMMEDIATE ok Now I try 0 > ." test" test ok 0 > which works fine. So does 0 > " test" TYPE test ok The following fails as the string is overwritten: 0 > " test" ok 2 > TYPE PEst ok I could not find the reason by quickly looking into it. Any ideas? Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

3 5

[Fwd: Re: [OpenBIOS] patch: machine dependent config]
by Segher Boessenkool 07 Jun '02

07 Jun '02

> > > Just a dumb idea, could we rewrite the preprocessing and testing > > > completely in C? I know that there are a lot of issues with perl on > > > > Nope, cpp can't do all that's necessary. Btw, once we have a working > > Forth compiler, we can use that to bootstrap itself :) > > You're talking about forth -> binary translation? That is not what we > want, I guess. Can you explain? There's three ways to represent a program: 1) Forth source 2) Forth dictionary (binary) 3) Forth dictionary/source (FCode) 3) is limited, but cross-platform; it's the prefered way for device manufacturers to distribute drivers, but there's no reason to implement our internal stuff with FCode. 2) is okay, but machine-specific. 1) is our prefered form. But that leads to a problem: the Forth compiler itself is written in Forth. So the "initial dictionary" will have to be distributed as 2). That's exactly what ref.pl + cpp magic do: they convert "pseudo-forth" source (engine.in) to dictionary. Now, what I said was: when we have the Forth compiler finished, we can have the engine.in compile a engine.fs, to replace itself. > > > newer platforms, which could make it hard to get paflof running on new > > > machines, even if we already have a gcc. Ugly though. If this is > > > > Cross-compilers save the day :) > > Cross compilers is exactly where this stops working. If I cross compile > for SH1 CPUs using a crosscompiler on Intel x86, my perl nor my gcc will > never tell me whether my 'long' is 32 or 64bit on the target platform. > We probably can't even use this to check for TI mode availability Sure you can; you just can't run the target programs, but of course the compiler knows the target data sizes :) > > I hope to finish the "Forth command group" today :) > > How much work has to be done here? One or two days, plus some cleanup, but that can be done later. > How far are we from being able to > read FCode with this (i.e. use the work in the fcode/base/ directory > already done? This is the Forth compiler, not yet the FCode compiler; that one is a lot easier. > Please make sure we don't do duplicate work here. I'll try :) > " text" is the only one missing to get the mandelbrot signature, one > of my toke test programs, running. Then we can start using the example > code and really testing the Fcode layer on top. I'll implement it without things like S" blabla(0d)(0a)blabla" etc., at first. It'll be here later tonight :) Segher - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] patch: machine dependent config
by Stefan Reinauer 07 Jun '02

07 Jun '02

* Segher Boessenkool <segher(a)chello.nl> [020607 13:23]: > > Except we rely on compiler defines and prerequisites to get towards a > > defined build set (which probably sucks). If we have to use this > > functionality anyways, it might be interesting to look at autoconf. > > But then again we won't get rid of all perl stuff, so using autoconf > > just adds another player to the game. > > Please let's not use autotools :) Besides their implementation is a bit far from the goal (portability), autoconf and friends cause lots of trouble, not only with new platforms but also with newer versions of autoconf etc. We definitely don't want that. > > Just a dumb idea, could we rewrite the preprocessing and testing > > completely in C? I know that there are a lot of issues with perl on > > Nope, cpp can't do all that's necessary. Btw, once we have a working > Forth compiler, we can use that to bootstrap itself :) You're talking about forth -> binary translation? That is not what we want, I guess. Can you explain? > > newer platforms, which could make it hard to get paflof running on new > > machines, even if we already have a gcc. Ugly though. If this is > > Cross-compilers save the day :) Cross compilers is exactly where this stops working. If I cross compile for SH1 CPUs using a crosscompiler on Intel x86, my perl nor my gcc will never tell me whether my 'long' is 32 or 64bit on the target platform. We probably can't even use this to check for TI mode availability > I hope to finish the "Forth command group" today :) How much work has to be done here? How far are we from being able to read FCode with this (i.e. use the work in the fcode/base/ directory already done? Please make sure we don't do duplicate work here. " text" is the only one missing to get the mandelbrot signature, one of my toke test programs, running. Then we can start using the example code and really testing the Fcode layer on top. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

2 1

patch: machine dependent config
by Stefan Reinauer 07 Jun '02

07 Jun '02

Hi, ok, this time I redid the patch to make paflof sane on 64bit platforms in a cleaner way, using abstracted defines that are dependent on certain platform specifics. As this is platform dependent stuff which has basically nothing to do with paflof itself, I moved it to a new file: machdep.h. I moved the sanity check out of paflof.c into machdep.c, which we will probably not need to link in case we know an architecture/compiler combination is sane. We really need to make sure we are 64bit clean from the beginning so we recognize early what problems we might have to face getting paflof portable. Segher, is this ok to check in from your side? If so, please do! Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)

2 5

Re: [OpenBIOS] 64bit paflof with lots of gnuisms
by Parag Patel 04 Jun '02

04 Jun '02

Re: macros vs sizes of various int/ptr types One reason I used explicit type definitions for INT_64 and PTR_64 is that SmartFirmware can be built with either 32-bit or 64-bit cells on hosts that support both. Thus I can't use the sizeof operators. Also sizeofs within #if macro expressions aren't supported by most compilers. SF doesn't use gcc's label/tables feature either. We just use a separate C function per Forth word. It's more than fast enough for boot-up purposes, but then almost all of the real work is done in C rather than Forth in any case. Just FYI, SF has been compiled with various C compilers including TI's 34020 graphics processor compiler, Metrowerks for several targets, Visual C, Apple's MPW C, and Sun's C/C++ compiler. Barring a few key machine-dependent assembly stubs, of course. -- Parag Patel - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

1 0

Re: [OpenBIOS] 64bit paflof with lots of gnuisms
by Parag Patel 04 Jun '02

04 Jun '02

In message <20020603181539.GB19105(a)suse.de>, Stefan Reinauer writes: > typedef intptr_t type_n; // cell size > typedef uintptr_t type_u; // cell size >+#if defined(__alpha__) || defined(__x86_64__) || \ >+ defined(__ia64__) || defined(ppc64) >+typedef intmax_t type_d __attribute__ ((mode (TI))); // 2 * cell size >+typedef uintmax_t type_du __attribute__ ((mode (TI))); // 2 * cell size >+#else > typedef intmax_t type_d; // 2 * cell size > typedef uintmax_t type_du; // 2 * cell size >+#endif > #else Dunno about the Gnu-isms, 'cause we avoid 'em in SmartFirmware, but as a general rule, you should change your defines to something like this: > typedef intptr_t type_n; // cell size > typedef uintptr_t type_u; // cell size >+#ifdef int64_type >+typedef intmax_t type_d __attribute__ ((mode (TI))); // 2 * cell size >+typedef uintmax_t type_du __attribute__ ((mode (TI))); // 2 * cell size >+#else > typedef intmax_t type_d; // 2 * cell size > typedef uintmax_t type_du; // 2 * cell size >+#endif > #else and have a machine-dependent section that sets int64_type (or whatever) based on the CPU type or some-such. Make the macros reflect the specific feature directly. We use two different macros defined in a machdep.h header file, which is customized for each platform and compiler. One macro determines the presence/absence of 64-bit ints (say INT_64BIT) and another determines if pointers will be 64-bits or not (PTR_64BIT). Only one place needs to specify the settings of these macros, machdep.h, and every other common source file is neatly disconnected from any machine dependancies. As for the Gnu-isms, we wrap the necessary code in #ifdef __GNUC__, in some cases creating a null macro to reduce the subsequent ifdef mess: #ifndef __GNU_C__ #define __attribute__(arg) /* noop */ #endif Obviously, there are other ways to deal with this as well. Just for what it's worth. -- Parag - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message http://www.freiburg.linux.de/OpenBIOS/ - free your system..

4 4

64bit paflof with lots of gnuisms
by Stefan Reinauer 03 Jun '02

03 Jun '02

Hi there, I played around with paflof on 64bit platforms. As we make heavy use of GNUisms, I got it working using some more. I'll attach 2 patches, one cleans up 64bit compile warnings for the fprintf stuff (cosmetic), the other fixes the double cell issue. Unfortunately it does not compile on 32bit platforms without the ugly #ifdef constructs. The error messages are "no data type for mode `TI'" I am not sure whether this is a gcc bug or rather an error in my thoughts. Any comments? See you, Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994)

1 0

Jump to page: