Recent Posts

Pages: [1] 2 3 ... 10
1
The Orphanage / Re: What will software engineering be like in 2022?
« Last post by mikeburr on Today at 10:15:27 PM »
i think some thing like this
History lesson
  in the 1960's and 1970's Iann Barron and chums produced the first true parallel processing environment
The still revolutionary Transputer and Occam

  in the late 1970's and 1980's Transmeta produced
The Code morphing compiler [and recently reincarnated in Russia ??]

  in recent times ‎Andreas Olofsson tried to reinvent the transputer and produced
The Epiphany co processor and associates the accompanying Parrallela language  [sadly its next incarnation .. the one they should have gone for seems to have stalled .. being a cycnic im not surprised by that ]

What will Happen ....
The latter idea is sort of where it will go in my opinion ....
My prediction is that the FGPA system will enable individuals to make specialised cluster "chips" .. eventually this will gather enough momentum that these groups will be able to form some thing like a computer-by-process and that enough of these processes"at a reasonable price" [its prohibitive at the moment] will be the basis of the next generation computer in the same way that Linux formed
an operating system first from a kernel and then the mish-mash of contributions by lots of enthusiasts mostly from the scientific and academic communities [due to their requirements as ordinary people only want 'to do a bit of keeping in touch with each other' and maybe a few basic accounts so they just need posh phones ] ...
The problem with computing has always been the Hardware software interface and this is partly relieved with FGPA [see below ]


 unfortunately you will have noticed that ....

politics and funding killed off the Transputer

IBM bought Red Hat Linux [the only decent Linux !!!] for 36 billion recently i think this will cast a long shadow over Linux

you will notice that Transmeta's offering was balatantly plaguarised by Intel and AMD in order to kill it off [and i would too if i was in their position]

that the incarnation of Epiphany [1024 cores 64 bit with a Zylinx chip attached ] isnt happening as far as i can see

Nvidia own many of the Linux based GUI API's

so you can fully expect that developments likely to cause issues with what is prodominantly American Big Business may well be bought out or swallowed up .. in fact if you come up with something innovative then dont expect to get much out of it [fact !!] and probably dont expect it to see much daylight as large companies are a bit like "collectors" so it might sit in a vault for a long time 

you will also be aware

much of the parallelisation and  optimisation of code in the x86 machine is in hardware not software as with the Transmeta offering
[ see various articles on the Itanium for a pleasant contrast in idealogy The Transmeta offering wasnt brilliant either but it was a bloody good first attempt considering the difficulties involved and how far evolved the competion was]
incidentally some of this has moved into ML64 {along with what i reckon is a lot of paranoia} which you will notice makes it rather bulky compared to its 32 bit parent


regards   mike b
2
Showcase / Re: MemStatTray UASM x64
« Last post by hutch-- on Today at 10:10:27 PM »
 :biggrin:

This sounds like an excuse for someone who was not willing to support their preferred assembler. Instead of writing library modules and a macro system designed to support their preferred assembler, they prefer to try and bludge it from the Microsoft assembler that does have library and macro support written to support the Microsoft assembler. Now the solution of course is to get off their arse and start producing the support system for John's hard work to get the assembler up and going. All it take is massive hours of writing and testing reliable 64 bit code to do that support.

As 32 bit slowly fades into history it becomes the last bastion of those too lazy to do the amount of work necessary to move to the next generation of super fast 64 bit applications.  :skrewy:
3
Showcase / Re: MemStatTray UASM x64
« Last post by jj2007 on Today at 08:41:00 PM »
then fix the UASM include files which were never properly updated to 64-bit then look for the definition of some macros that appear out of the blue

The origin of the problem is Microsoft's decision to cripple the 64-bit version of MASM, and the subsequent attempts to work around the crippled assembler thus excluding the almost perfect alternative UAsm. The confusion is not healthy. Fortunately, I couldn't care less, 32 bits are enough for me :tongue:
4
Showcase / Re: MemStatTray UASM x64
« Last post by AW on Today at 04:34:02 PM »
Quote
The libraries including source code are always available at the github repository: https://github.com/mrfearless/ModernUI and https://github.com/mrfearless/ModernUI64

I have not seen it because it is not pinned in https://github.com/mrfearless, I should have looked better.

Anyway, it is always a PITA to build when we are dealing with libraries we are not used to, then fix the UASM include files which were never properly updated to 64-bit then look for the definition of some macros that appear out of the blue. This does not apply specifically to the MemStatTrayx64 or to your good work in general.

5
 :biggrin:

> the new SDK are written in a way that they can't work with Uasm.

the new SDK are written in a way that they work with MASM.

Other assemblers using MASM resources has been going on since the start of the MASM32 sdk, i guess this latest incarnation is much the same.

I think John has done great work but I am fascinated by the lack of support by its user base when what is needed is a group of users who write their own library and macros.
6
Showcase / Re: MemStatTray UASM x64
« Last post by fearless on Today at 07:38:03 AM »
I wonder why you did not provide the 64-bit versions of the ModernUI libraries, including source code, required to build your program
The libraries including source code are always available at the github repository: https://github.com/mrfearless/ModernUI and https://github.com/mrfearless/ModernUI64

I didn't include them mainly due to lazyness.

A possible cause for the bug is a defective translation to 64-bit.
Yes its possible there is some bugs in the porting process - I will try and look into it when I get a chance - the x64 version of the libraries are always a little bit behind and any fixes in the x86 version might not have been implemented in the x64 version - or I overlooked/forgot to do them.
7

UAsm is practically bug free and 3 to 5 times faster than MASM, but unfortunately the 64-bit macros of the new SDK are written in a way that they can't work with Uasm. My advice: stick with 32-bit code :tongue:

Hi jj2007,

new macros work fine under uasm, just need a little correction  :azn:
8
Masm is ok up to version 10 or so, later versions have all sorts of problems, see Discovering the mysteries of MASM features

UAsm is practically bug free and 3 to 5 times faster than MASM, but unfortunately the 64-bit macros of the new SDK are written in a way that they can't work with Uasm. My advice: stick with 32-bit code :tongue:
9
The Soap Box / Re: My whine of the day about Win10 64 Pro.
« Last post by K_F on Today at 04:53:23 AM »
Hirens maybe ?
10
The Soap Box / Re: My whine of the day about Win10 64 Pro.
« Last post by Vortex on Today at 04:15:47 AM »
Hi Hutch,

The System Volume Information folder is difficult to delete under Windows. My solution is to boot the system with a live Linux distribution and delete that folder.
Pages: [1] 2 3 ... 10