If I don't specify the output parameter, html is taken as default.
It seems correct to me, but the help should say it.
for the other output parameters see my Question No.2
tiziano
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michael Van
Is there high level operator/(inline)function for rotating bits?
Am I supposed to implement rotating bits (like ror/rol in i386 asm) by inline
assembler or some ugly workarounds (shifts and or-s)?
___
fpc-pascal maillist -
On 24 mei 2006, at 10:56, Пётр Косаревский wrote:
Is there high level operator/(inline)function for rotating bits?
No.
Am I supposed to implement rotating bits (like ror/rol in i386 asm)
by inline assembler or some ugly workarounds (shifts and or-s)?
Yes. I think there's already a
On 24 mei 2006, at 10:56, Пётр Косаревский wrote:
Is there high level operator/(inline)function for rotating bits?
No.
Am I supposed to implement rotating bits (like ror/rol in i386 asm)
by inline assembler or some ugly workarounds (shifts and or-s)?
Yes. I think there's already a
I don't know how to use ret to achieve the same goal with fewer
commands.
Well, if I get it right (and it works on my system), the last lines:
movb %al,result etc. (6 times) should be commented out.
___
fpc-pascal maillist -
đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ wrote:
On 24 mei 2006, at 10:56, đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ wrote:
Is there high level operator/(inline)function for rotating bits?
No.
Am I supposed to implement rotating bits (like ror/rol in i386 asm)
by inline assembler or some ugly workarounds (shifts and or-s)?
Yes. I think
With register calling convention (which is the default calling convention
in FPC 2.x), it can be reduced just to:
function brol(b: byte; c: byte): byte; assembler; inline;
asm
rolb %cl,%al
end;
(and similarly for all the other functions). The first parameter goes to
eax, the second to
On 24 mei 2006, at 16:11, Пётр Косаревский wrote:
function brol(b: byte; c: byte): byte; assembler; inline;
asm
rolb %cl,%al
end;
(and similarly for all the other functions). The first parameter
goes to
eax, the second to ecx, and the result is supposed to be in eax
again.
Tomas
With register calling convention (which is the default calling convention
in FPC 2.x), it can be reduced just to:
function brol(b: byte; c: byte): byte; assembler; inline;
asm
rolb %cl,%al
end;
(and similarly for all the other functions). The first parameter goes to
eax, the second to
Hi all,
Is FPC ready for writing libraries callable from C/C++ on Win32 and Linux?
Cheers,
Krishna
--
You think you know when you learn, are more
sure when you can write, even more when you
can teach, but certain when you can program
- Alan Perlis
Hi all,
Is there any particular reason for not compressing the release
tarballs (Linux f.e) with say bzip2 or even 7zip? The uncompressed
tarball weighs in around 24M and I'm sure bzipping will reduce it by a
large margin.
Cheers,
Krishna
--
You think you know when you learn, are more
sure
On 24 mei 2006, at 17:09, Пётр Косаревский wrote:
function brol(b: byte; c: byte): byte; assembler; inline;
asm
rolb %cl,%al
end;
(and similarly for all the other functions). The first parameter
goes to
eax, the second to ecx, and the result is supposed to be in eax
again.
Tomas
Did
Krishna wrote:
Hi all,
Is there any particular reason for not compressing the release
tarballs (Linux f.e) with say bzip2 or even 7zip? The uncompressed
tarball weighs in around 24M and I'm sure bzipping will reduce it by a
large margin.
Not really because it is simply a tar ball of
Пётр Косаревский wrote:
On 24 mei 2006, at 10:56, Пётр Косаревский wrote:
Is there high level operator/(inline)function for rotating bits?
No.
Am I supposed to implement rotating bits (like ror/rol in i386 asm)
by inline assembler or some ugly workarounds (shifts and or-s)?
Yes. I think
On 24 mei 2006, at 17:30, Florian Klaempfl wrote:
Not really because it is simply a tar ball of several .tar.gz. Because
gzip is spread wider, we use this instead of bzip2/7zip.
Isn't bzip2 available more or less everywhere nowadays? (at least
where gzip is available, and in particular on
Jonas Maebe wrote:
On 24 mei 2006, at 17:09, Đ#65533;Ń#65533;Ń#65533;Ń#65533;
Đ#65533;ĐžŃ#65533;Đ°Ń#65533;овŃ#65533;киК wrote:
function brol(b: byte; c: byte): byte; assembler; inline;
asm
rolb %cl,%al
end;
(and similarly for all the other functions). The first parameter
goes to
Jonas Maebe wrote:
On 24 mei 2006, at 17:30, Florian Klaempfl wrote:
Not really because it is simply a tar ball of several .tar.gz. Because
gzip is spread wider, we use this instead of bzip2/7zip.
Isn't bzip2 available more or less everywhere nowadays? (at least where
gzip is available,
Krishna wrote:
Hi all,
Is FPC ready for writing libraries callable from C/C++ on Win32 and Linux?
Yes.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
There is this page which might help some
http://www.merlyn.demon.co.uk/del-bits.htm
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Krishna wrote:
Hi all,
Is FPC ready for writing libraries callable from C/C++ on Win32 and Linux?
Yes.
Just that C++ objects aren't compatible, since the implementation of object
orientation is
slightly/majorly different between languages so you would have to use mainly
procedural
Mantis is now embedded in a freepascal page, the problem is that for
those who use 800x600 screen resolution (like me in at least one
place). The sidebars (left, top) takes a big amount of screen. The
result is not too pretty. see:
http://mx.geocities.com/jesusrmx/lazarus/images/sample26.png
At
First parameter is in eax, second in edx (third one is ecx)
TH Yes, of course, sorry for confusion... :-( Anyway, loading of the first
TH parameter can be still skipped (and the stack frame is probably not useful
TH in this case either). So you'd get:
TH function brol(b: byte; c: byte): byte;
L There is this page which might help some
L http://www.merlyn.demon.co.uk/del-bits.htm
Thank you, it was interesting.
But it was not very helpful.
It's interesting, that they don't seem to care much about rotating
bytes or words. (Asm rotating 64-bits was fascinating!)
FK Jonas Maebe wrote:
On 24 mei 2006, at 17:30, Florian Klaempfl wrote:
Not really because it is simply a tar ball of several .tar.gz. Because
gzip is spread wider, we use this instead of bzip2/7zip.
Isn't bzip2 available more or less everywhere nowadays? (at least where
gzip is available,
Because gzip is spread wider, we use this instead of bzip2/7zip.
I think the size saved by compressing FPC with bz2 would be much
greater than the size of downloading and installing a bzip2 extractor.
- Jeff
___
fpc-pascal maillist -
On 25 May 06, at 0:10, ϸňđ Ęîńŕđĺâńęčé ń mail.ru wrote:
First parameter is in eax, second in edx (third one is ecx)
TH Yes, of course, sorry for confusion... :-( Anyway, loading of the first
TH parameter can be still skipped (and the stack frame is probably not useful
TH in this case
On 5/24/06, Пётр Косаревский с mail.ru [EMAIL PROTECTED] wrote:
FK Jonas Maebe wrote:
On 24 mei 2006, at 17:30, Florian Klaempfl wrote:
Not really because it is simply a tar ball of several .tar.gz. Because
gzip is spread wider, we use this instead of bzip2/7zip.
Isn't bzip2 available more
27 matches
Mail list logo
