Hi Segher and others,
I made a little patch for paflof so it automatically recognizes the
cell size of the machine it is compiled on. It can probably be done
nicer, but I got sick of changing the code while changing machines ;)
Should I commit this?
Best regards,
Stefan Reinauer
--
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)
Dear sirs,
Good day to you!
We are Renhe Industrial Parts Co., Ltd. from China. I find your company from the internet search and have learnt something about your company. I feel like doing business with your company.
Our Renhe Industrial Parts is a big trading company in Ningbo China. The main business in our company is importing and exporting, and quite a lot of other businesses. Our company owns some subcompanies and some business friendship companies. These companies manufacture various products, including molds, casting products, rubber and plastic products. We also can provide you with OEM parts (such as stampings, CNC machining ,weld assemblies, stainless Fabrication and so on).
We can find good source for our customers because I have ten years worked in the trading fields and much familiar with the products and factories in our province. We have got rich experiences in trading, especially in exporting die-casting products, casting products, plastic products ,moulds and OEM parts. All these products were sent to many companies in Europe, America, Japan and so on. For instance, some parts have been used in GM company in America, some parts to PHILIP company for Cable TV Case ,and also for power tools ,washing machines , pumps and so on.. All these products are well appraised.
Advanced equipment is used in producing, inspection, and testing (such as CMM. PI. Spectrum analysis equipment and so on). Our target is not only in grade of products but in chasing high quality as well.
Now most of subcompanies has obtain ISO9002 quality system certification, and also some companies have obtain QS9000 and VDA6.1 certification.
If you have any interesting in sourcing from China in casting products, plastic parts, mould and other OEM products, we would be a good partner. Please email me or fax me. I will reply you ASAP.
Best Wishes,
Chen Qunli
Renhe Industrial Parts
Tel: 0086-574-87672567, 87806525
Fax: 0086-574-87806761,87672528
Mobil: 0086-13857464822
Add: 206,#5,Lane 18
Zhenda Road,
Ningbo, 315000
China
Hi,
I made some updates to the tokenizer and detokenizer, mainly bug fixes.
Toke 0.4 changes since the last release (0.2)
---------------------------------------------
* abort" is tokenized now. This is not really defined by IEEE,
but it is used in some Apple FCode driver examples, and thus
should at least do something. Using abort" in FCode programs
emits a warning when running toke.
* endif works. In Forth if clauses are written as
condition? if ... then
However, a lot of forth implementations know if..endif as well
as it sounds a bit more natural
* name is an alias for device-name. Added to fit common usage.
* parsed numbers can contain dots to make reading easier.
* fcode number counter resetted when tokenizing multiple files.
* hex values that are embedded in strings work properly now.
* better IEEE compliance (no definitions within definitions etc)
* other small bugfixes.
Detok 0.5.2 changes since last release (0.3)
--------------------------------------------
* case..endcase expressions are now detokenized correctly
case expected an offset value, which is not true according to IEEE
* detok is more silent per default now.
* compilation on some systems that seem to have broken headers for
getopt() should work. (Thanks to Tim Barret)
* When an FCode word is unnamed, always print the FCode number
(Tim Barret)
* Indent size is 4 now to make output more readable.
* line numbers or byte offsets within the detokenized fcode file can
be shown
* checksum calculation works.
* Input files are buffered (slightly better performance ;))
* pretty printing of strings with nonprintables fixed.
* support for 64bit extension fcode words.
* other small bugfixes
Additionally I started to put some Forth code into CVS, which
implements some of the base fcode words from the IEEE 1275.
You can have a look at
http://openbios.ph-freiburg.de/cgi-dom/viewcvs.cgi/fcode/base/
Currently some data type conversions and stack operations are
implemented, but its far from being complete. This should give you
an idea how Forth words of IEEE 1275 can be implemented easily
Every section in the source files contains the topic number as described
in the ieee 1275 standard.
A lot of sections are missing. Feel free to choose one, drop a note on
this list that you want to work on it and start coding ;)
Any quastions and comments are highly welcome! It's time to get things
started - would be a nice christmas present to have the first machine
booting some openbios version by the end of this year ;)
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..
Hi,
after feeding the SymbiosLogic 825 FCode driver from Apple
( http://www.freiburg.linux.de/OpenBIOS/bin/AAPL-8250.4th )
to the tokenizer I found that the old implementation of
abort" was not really doing what it should. According to
IEEE 1275 it is an equivalent to -2 throw, which I implemented
as a macro.
This would not work and not behave like it should, so I replaced
it:
flag? abort" text"
is now tokenized to:
flag?
if
" text" type
-2 throw
then
Is this the wanted behaviour? Any ideas?
Best regards,
Stefan Reinauer
--
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..
* John R. Hogerhuis <jhogerhuis(a)yahoo.com> [020521 07:14]:
> Ok, I downloaded paflof, got it building. I think
> you're right, Segher's code looks pretty clean. Just
> out of curiosity, I think there are forth-in-Cs
> already implemented under GPL, why not use one of
> them?
Most of what I've looked at is nice, but uses a different approach
than what we really want. Either they compile to native code, which
is nice, but not really needed and it makes the thing bigger and more
complex than needed. Others try to care for lots of system
interoperation issues which we don't really need. Starting from scratch
normally looks like a not too smart idea, but in this case i think it
is, as we know exactly that we have no overhead whatsoever.
Even with lots of optimazation it might be hard to get gforth or alikes
down to the size paflof has, or will have, when it's done.
Every byte we safe here, means we have more space for the packages that
will live on top of paflof, be it the debugging facilities, drivers, ...
> How do I know which words still need implementation?
> How do I take ownership (make sure no duplication of
> work).
The only source is the code, and probably Segher ;) None of the
highlevel words, like package handling, properties, exceptions,
have been touched in connection with paflof. It probably makes sense to
push these forward until paflof is far enough to be able to execute
fcode.
Also the existing tokenizer/detokenizer need a lot of testing, which I
can only do little, as I am not a long time forth expert. ;)
For taking ownership for a certain task just drop a note to this list
about what your ideas are. This list has been low or rather zero traffic
for a while; As far as I know only Segher and me are looking at the code
currently so chances that you do duplicate work are naturally pretty
low.
> I've started reading the IEEE 1275 spec, I should be
> done soon.
For anyone interested, this is the main information source that should
be used for implementation - A lot of information is available in the
Docs section of the OpenBIOS homepage:
http://www.freiburg.linux.de/OpenBIOS/docs/
> Feel free to respond to me on the list rather than
> directly. I'm subscribed now, but I wasn't sure how
> basic of information you wanted showing up on the
> list.
I think it is a good idea not to keep this discussion secret, as
there's enough to do for _a lot_ of developers ;)
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..
Hello,
I'm plodding my way through OF1275.
In section 3.2.2.3.1 reference is made to the Forth
words
DEFER
INSTANCE
BUFFER:
I couldn't find these in the DPANS94 spec... anyone
know what these are? I never did much with ANS Forth,
so I am not sure why I can't find these words in the
docs. Perhaps INSTANCE and BUFFER: are specific to OF?
I assume DEFER is for deferred definition/vectored
execution words. Why isn't it in ANS spec?
Thanks,
-- John.
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
-
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..
