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 a
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 cas
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 - fpc-pascal@lis
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
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!)
__
>> 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
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 hi
> 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
pr
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.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
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 a
Jonas Maebe wrote:
> 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
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 L
Пётр Косаревский 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)?
>> Y
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
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 y
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 whe
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
___
> 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 seco
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
Well,
> 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 seco
đŁÔŇ ëĎÓÁŇĹ×ÓËÉĘ 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)?
>>
> 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 - fpc-pascal@l
> 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
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 featur
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 - fpc-pascal@lists.freepascal.
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 Ca
27 matches
Mail list logo
