Recent

Recent Posts

Pages: [1] 2 3 ... 10
1
macOS / Mac OS X / Re: getattrlist()
« Last post by Thausand on Today at 11:40:19 pm »
Free Pascal univint unit xattr there find getxattr that can use ?
2
Where the Hell did you get HDMI from?????
Oh... I was think it is star and need take picture with Pico  :D
3
macOS / Mac OS X / getattrlist()
« Last post by comdora on Today at 11:26:50 pm »
Hi,
is there getattrlist() method implemented
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/getattrlist.2.html

in lazarus, or I should load it from library? 

I just still don't know which library it is.

Regards
Bojan
4
Beginners / Re: Parallel programming model
« Last post by MarkMLl on Today at 10:52:42 pm »
The main difference with ARM is, that it has a lot of conditional opcodes. The good: much less branching. The bad: you have to execute both if you want maximum speed. But because it's just a single opcode and the registers and execution units on CPU's are highly virtualized anyway, that's a net gain. As long as you don't want to run a long pipeline, that is.

I know what you mean, but I suspect a better term is /predicated/... and I'm not sure it's survived in aarch64.

Quote
For the big picture: a current x86 CPU is a VM that emulates one. And it is filled with VM's that emulate execution units. Because the x86 architecture and opcodes do really poorly if you want to multiplex and multitask. But that's what everyone uses, so that's what you have to run.

Again, I think I'm with you. But if the stuff I was reading three or four years ago is still valid it's interesting that recent(ish) Intel chips appear to use microcode triplets internally, i.e. have surprising echoes of IA-64.

MarkMLl
5
General / Re: Lazreport join two reports
« Last post by korba812 on Today at 10:52:42 pm »
Yes. Use TfrCompositeReport component for this purpose. Check sample project in "components\lazreport\samples\editor" directory.
6
Beginners / Re: Parallel programming model
« Last post by SymbolicFrank on Today at 10:38:17 pm »
The main difference with ARM is, that it has a lot of conditional opcodes. The good: much less branching. The bad: you have to execute both if you want maximum speed. But because it's just a single opcode and the registers and execution units on CPU's are highly virtualized anyway, that's a net gain. As long as you don't want to run a long pipeline, that is.

For comparison: CMOVE on x86 is one of the major speedups.

For the big picture: a current x86 CPU is a VM that emulates one. And it is filled with VM's that emulate execution units. Because the x86 architecture and opcodes do really poorly if you want to multiplex and multitask. But that's what everyone uses, so that's what you have to run.

On a higher level, a modern PC is just like an ancient one, with a bunch of stuff tacked on. Or a collection of them, like the virtual 8086 modes of an 80386, but with less fencing. Sharing all resources.

We're used to big cores that use time slices for multitasking, with unified memory and other resources. It's like the right-wing idea of liberalism: everyone should be able to do whatever they want. Like, driving on each side of the road, however they feel like.

Your storage units (disks, memory, websites), all contain a long string of ones and zeroes. The contents are just random noise unless you know the protocol used to store them all. It is a huge chain of conventions. And processing is just a set of binary instructions, which are executed without any understanding. And they're part of that data storage as well.

So, the trick is in optimizing understanding: the hard- and software needs to know what this sequence of bits represents and how they can interact with it. And, especially, what the programmer wants to happen.

Together with the pitfalls of unified resources, as discussed above, and transistors being dirt cheap, it makes a lot more sense to partition things as far as they go. And spend half your hardware budget on optimizing random communications between all the tasks, floating around and/or in the process of being executed.
7
The pico just not has enough space/memory to run anything like hdmi.... It is a MC.
But it can run a two line LED display easily.

Where the Hell did you get HDMI from?????

The HD44780 is a minimal LCD controller, so well-known it even has a Wp page.

Besides https://hackaday.com/2021/02/12/bitbanged-dvi-on-a-raspberry-pi-rp2040-microcontroller/

MarkMLl
8
General / Re: python for lazarus
« Last post by AlexTP on Today at 10:10:23 pm »
I am not sure Python4Lazarus lacks something, yes it lacks 'PyObject_SelfIter' symbol, but Python4Delphi (original project) lacks it too!
9
General / Re: python for lazarus
« Last post by suibaf on Today at 09:05:59 pm »
As yuo can see with thonny the code python work, inside the lazarus app no!
Thank you
10
Beginners / Re: A problem with Firebird Embedded 2.5
« Last post by rvk on Today at 09:05:57 pm »
Correct. Use something that can be maintained from the start, not something that gives your customer headaches if something happens to you.
ALWAYS use industry standards. Firebird is not one of those.....
Hahaha, and FPC and Lazarus aren't industry standards either.
So by that logic... Stay away from FPC and Lazarus if you don't want to give your customers headaches if something happens to you  :D
Pages: [1] 2 3 ... 10

TinyPortal © 2005-2018