Since it's missing the Pas2JS specific forum, I don't know if here is correct
place to post things about "Pas2JS".
I'm using it a lot and it's very promising. I came across with issue when
dealing with array of records.
I would like to convert this little piece of DWScript code to Pas2JS,
unfor
On 09.01.2018 08:04, Sven Barth via fpc-pascal wrote:
But you need to program in a way that allows the usage of multiple,
different types. That can more often than not lead to worse performance.
Seemingly it is done that way.
I rather often did a kind of "Generics" in ANSI C by using Macros. It
On 10/01/18 17:06, Martok wrote:
Afaik there are only two limitations:
* routines containing assembly blocks (including pure assembly routines)
cannot be inlined> * regular procedures that contain assembly blocks will never
use regvars
Somehow I have a feeling that the fix for one would also
2018-01-10 18:09 GMT+01:00 Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu>:
> Hi,
>
> On Wed, 10 Jan 2018, Matias Vara wrote:
>
> > BTW, this only applies to inline assembler functions rigth? In the case
> > of normal procedures that contains a block asm end; there is no problem,
> > Am I
Hello,
2018-01-10 18:03 GMT+01:00 Karoly Balogh (Charlie/SGR) <
char...@scenergy.dfmk.hu>:
> Hi,
>
> On Wed, 10 Jan 2018, Matias Vara wrote:
>
> > Thank you very much Karol, I completly missed this point during the
> > development of my kernel (Or maybe I had in mind sometime ago but I
> > forgot
Hi,
On Wed, 10 Jan 2018, Matias Vara wrote:
> BTW, this only applies to inline assembler functions rigth? In the case
> of normal procedures that contains a block asm end; there is no problem,
> Am I right?
No, it applies to *ALL* assembler code. Also inline blocks. The only
difference is, for b
Hi,
On Wed, 10 Jan 2018, Matias Vara wrote:
> Thank you very much Karol, I completly missed this point during the
> development of my kernel (Or maybe I had in mind sometime ago but I
> forgot it)It was only when I decided to play with -02 that all these
> issues arrised.
BTW, your code (as sho
BTW, this only applies to inline assembler functions rigth? In the case of
normal procedures that contains a block asm end; there is no problem, Am I
right?
Matias
2018-01-10 17:51 GMT+01:00 Matias Vara :
> Thank you very much Karol, I completly missed this point during the
> development of my k
Thank you very much Karol, I completly missed this point during the
development of my kernel (Or maybe I had in mind sometime ago but I forgot
it)
It was only when I decided to play with -02 that all these issues arrised.
Matias
2018-01-10 17:34 GMT+01:00 Karoly Balogh (Charlie/SGR) <
char...@sce
Hi,
On Wed, 10 Jan 2018, Matias Vara wrote:
> Hi Karol and thanks you very much! I got confused with the function
> names, I feel very sorry.As I said in my previous email, I fixed by
> rewriting the assembler function. However, I don't why it worked.
By accident. Simply the register/stack/memo
Hi Karol and thanks you very much! I got confused with the function names,
I feel very sorry.
As I said in my previous email, I fixed by rewriting the assembler
function. However, I don't why it worked.
So I understand you correctly, if I use assembler in my procedures there
could be a risk that I
Hi,
On Wed, 10 Jan 2018, Matias Vara wrote:
> I am getting an exception when I enable the -O2 optimization. More
> precisaily, the line that stars with write_portd is corrupting the
> data section. This is the pascal code:
>
> function PciReadDword(const bus, device, func, regnum: UInt32): U
Hi,
> variables in the same routine. Unlike in e.g. gcc, there are no
> annotations for assembly routines that they expect certain variables to
> be in memory and/or registers, that the block may touch arbitrary memory
> locations, etc. Hence, the compiler is as conservative as possible.
This t
I think the problem was the way write_portd() is implemented:
procedure write_portd(const Data: Pointer; const Port: Word); {$IFDEF
ASMINLINE} inline; {$ENDIF}
asm // RCX: data, RDX: port
{$IFDEF LINUX} mov dx, port {$ENDIF}
mov rsi, data // DX=port
outsd
end;
If I replace with somethin
Thanks for the history. Comp has always puzzled me before, especially
with these two functions from the RTL
function MSecsToTimeStamp(MSecs: Comp): TTimeStamp;
function TimeStampToMSecs(const TimeStamp: TTimeStamp): comp;
I assume that these have come down from Turbo Pascal - but it still
seem
Hello everyone,
I am getting an exception when I enable the -O2 optimization. More
precisaily, the line that stars with write_portd is corrupting the data
section. This is the pascal code:
function PciReadDword(const bus, device, func, regnum: UInt32): UInt32;
var
Send: DWORD;
begin
Send
AFAIK there is a small difference between comp and int64
COMP is 63bit + sign bit
int64 is 2s complement.
I hope I am right here.
Markus
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinf
> note that constants related to the windows 10 virtual terminal are not
> defined in FPC yet.
Correction: They were not added as of 3.0.4.rc1, they have been added now, not
sure exactly which version they are/were included.
James
-Original Message-
From: fpc-pascal [mailto:fpc-pascal-
If all you want is colors and simple positioning, you could use Ansi escape
codes instead of the CRT unit, then you would not have the issue with
redirection and CRT not being supported. Windows 10 builds after 10586 have
re-enabled Ansi escape codes, however after build 14393 it is no longer
On Wed, 10 Jan 2018 09:04:12 +0100
Jonas Maebe wrote:
> Mattias Gaertner wrote:
> > Comp is Int64 div 1.
>
> No, that is currency. Comp is a plain 64 bit integer. It originally
> comes from Turbo Pascal, which did not have a regular 64 bit integer
> type. The x87 fpu can be used to perform
Mattias Gaertner wrote:
> Comp is Int64 div 1.
No, that is currency. Comp is a plain 64 bit integer. It originally
comes from Turbo Pascal, which did not have a regular 64 bit integer
type. The x87 fpu can be used to perform 64 bit integer math though, so
it was originally a 64 bit integer typ
21 matches
Mail list logo
